Hey all, I'm submitting a support ticket for this, but I'd like to see if anyone else has been experiencing the same thing. I have a three page survey. We're experiencing major crashes and micro-crashes. * Major crash: The field application closes unexpectedly. Upon re-opening, the user is prompted to continue where they left off. * Minor crash: After backing out of a saved draft and going back into it, they open to a blank page. They are able to move to page 2 and complete the survey. In both cases, the end result is the same: they successfully submit the survey, but only data from the first page is submitted. This is EXTREMELY problematic, as frequently this is across several surveys and repeats miles apart from each other. Has anyone else experienced this? I'm wondering if it would be fixed by removing the pages and having it just on one long page, but the user experience for that would suck; this is a very long survey.

The cell highlighted in red is the error/warning. Excel based validation for question types and field names. It used to be explicitly stated in the documentation that the name column had to be unique across all tables as an XLSForm limitation. It looks like they've adjusted it to say it's unique across layers, so maybe it's now officially OK, but users till report a lot of issues when you do it this way. It's probably not the cause of the crash you are seeing but I can't recommend it.

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Crashing leads to only data from the first page of a survey getting submitted?

AlfredBaldenweck

Hey all,

I'm submitting a support ticket for this, but I'd like to see if anyone else has been experiencing the same thing.

I have a three page survey. We're experiencing major crashes and micro-crashes.

Major crash: The field application closes unexpectedly. Upon re-opening, the user is prompted to continue where they left off.
Minor crash: After backing out of a saved draft and going back into it, they open to a blank page. They are able to move to page 2 and complete the survey.

In both cases, the end result is the same: they successfully submit the survey, but only data from the first page is submitted.

This is EXTREMELY problematic, as frequently this is across several surveys and repeats miles apart from each other.

Has anyone else experienced this?

I'm wondering if it would be fixed by removing the pages and having it just on one long page, but the user experience for that would suck; this is a very long survey.

Najděte více příspěvků označených jako

Accepted answers

All comments

CodyPatterson

Hey @AlfredBaldenweck

I had a few instances of the Major-crashes you're describing, I ended up finding that it was due to a repeat table inside of my survey, which I had removed to fix it. If there's a for-sure way to intentionally replicate a major or minor crash, I would rebuild a test survey from the ground up, and add one section at a time to see if you can replicate it.

Cody

AlfredBaldenweck

Unfortunately, I can't replicate on demand, which is why the last support case ended. I have a nested repeat on page two. I cannot remove the repeats without having to completely rethink the entire workflow.

In my own experience, I'll get the crash towards the end of page two, but I often don't have any crash at all. My user took it for a heavy spin yesterday and basically got only two usable surveys out of the 7 she did.

It's weird because after a crash, I'll still have the data on page 2 from before the crash when I reopen it, but it's like the entire record became unmoored from itself so anything I do just floats away into the ether.

The general format is:

Page 1: Main table
Page 2: Repeats
Page 3: Main table: finishing up
Main Table: Questions with no assigned page, meaning they float on all pages

Only page 1 ever gets submitted for me.

ChristopherCounsell

Can you share your XLSForm?

What version of Survey123 Connect was used to publish the survey, and what version of the Survey123 field app?

Do you have logs from the field app?

Do you have any additional information around the workflow up until this point? Like high volume of submissions, device type, literally anything?

Did the issue only start occurring recently?

AlfredBaldenweck

Yeah, I have a log and the Excel form.

I'll attach the form here. Not sure what all information is in the log so not sure if it's something that can be shared publicly. Sorry that it's kind of messy, but it is very long and there's a lot of stuff happening in it.

One thing that I think might make a difference and I'm going to try is that I have the pages set up by relevance, rather than by body::esri:visible. I'm making the switch and going to ask my user to test it.

Happens on iOS and Android. Been happening a bit here and there through testing over the last few months of development, but I haven't been able to make it happen for weeks, and then my user had 5 in the same day while putting it through its paces. And of course, I can't replicate on demand.

On a related note, Survey123 really needs logging to be a permanent setting.

RLFO_Realty_ROW_Inspections.xlsx

Neal_t_k

You have some duplicate fields. Might be causing issues when both are relevant. Obviously they are in different tables, but I try to avoid any duplicate field names.

AlfredBaldenweck

That's not a bad idea. I just hate the idea of naming what is essentially the same field with the same function differently

ChristopherCounsell

It's not valid survey123 design. It should throw a data validation error in Excel. If you successfully publish the survey form, you may encounter issues in the app or website, like what you are seeing now.

AlfredBaldenweck

It doesn't throw an error and successfully publishes because they belong to two or three different tables. It would follow that if it can publish, it should be good to go, or we need to do some serious tuning up of our error checking. If the true intent of the team is that you can't have two different tables with a "siteID" field in the same survey, that would be very surprising and inspire a fair bit of dismay.

The other thing is that it isn't like it's a consistent thing. It happens for me personally one out of like, every 15 surveys. It happened to my user more but I think that part of it is she was switching between saved drafts. Another wrinkle is that she had preloaded the surveys the night before and I had pushed an update that didn't change the schema but did change some form behaviour. I myself have not run into that because I only do one survey at a time and never pre-load them.

ChristopherCounsell

It seems like it's tied to the calculations.

There's a lot of them within the form, some complex, with calculation mode set to Always. Good change that at some stage - particularly with a lot of repeat entries - the device is running out of memory and just crashing.

More specifically it could be tied to calculating positions and counts of repeats, and the use of pages. There has been discussion previously on this including some defects lodged. This ties in well with the behaviour you're seeing where issues manifest across the pages

https://support.esri.com/en-us/bug/in-the-arcgis-survey123-field-app-version-318145-ios-de-bug-000162468

https://community.esri.com/t5/arcgis-survey123-questions/survey123-survey-crashing-on-ipad-related-to/td-p/1474181

https://community.esri.com/t5/arcgis-survey123-questions/indexed-repeat-circular-reference-warning-is-it-ok/td-p/1474937

With the Survey123 team focusing on the 4.x release for 2026 I don't anticipate that your issue will get resolved. Maybe if you can explicitly identify the steps to reproduce and go through the support gauntlet...

I would instead recommend simplifying the survey. Some ideas:

Use collapsed groups instead of page style
Move calculations to post-processing e.g. a scheduled Notebook or database trigger.
Calculate once, not always. This can be achieved with a 'ready to submit' button that applies relevancy on the count or other fields
Remove unnecessary fields or calculations to streamline your survey
Consider breaking up the survey into a multi-part workflow using custom URL schemes to target the repeats.

AlfredBaldenweck

Hmm. Well, upon reviewing my one use of position(..), it turns out that was an artifact from an earlier configuration I had of these tables, so I just took it out lol.

I'm going to push a test changing the relevance, calculation modes, and without that one position(..) and see if that helps.

From a UX perspective, having to scroll endlessly kind of sucks, so I'm hoping to maintain pages. If we keep crashing, those will be the next to go. It'd be different if the jumping behaviour didn't suck so bad.

Thanks for your help, Chris. Still waiting for Tech Support to get back to me, but hopefully we'll get this straightened out.

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.