Survey123 app crashes permanently with files in draft folder

11-17-2020 02:45 AM
New Contributor II


We recently had some trouble with the Survey123 App. The app was used for the registration of plant species at 44 different field locations.

Those 44 forms were saved in the draft folder during the day, when the app suddenly crashed. After that it was no longer possible to open the app. Only a re-install solved the issue, but all data in the drafts were deleted.

We now try to understand what exactly happened. We learned about the “maximum record count” (1000 records) and we were wondering if this caused the crash. In this regard we were confused about what counts as a record. We assumed that each point (form) counts as one record (regardless of how many species and variables are registered at each point). Is that right? Or do all plant species at one point count into the total record count? In this case - if we would register 30 different species per point - the total amount would be 44x30=1360 records.

However, if it is not the record limit that causes the crash, does the draft folder has any limitation of how many drafts can be stored there at the same time?

Of course, the most likely reason might simply be a conflict between the app and the iPad, but we would like to exclude other possible issues (as those mentioned above).

We would appreciate a lot if someone can help us to understand.


(Btw: we used the newest Survey123 version on an Apple iPad with IOS)


Kind regards,


Tags (4)
0 Kudos
2 Replies
Esri Regular Contributor

Hello @ulb


Typically the "Maximum record count" refers to the number of features that can be returned in a single request and is usually used in the context of service performance. I haven't heard it used in a record submission context before. 


When you say species and variables is that referring to related records (repeats), or choices in a choice list? Unless the survey was quite large with a lot of choices (thousands to hundreds of thousands of choices in the choices sheet) and repeats etc. I wouldn't expect 44 records with repeats to cause the app to crash. 


Would I be able to obtain a copy of the XLSForm I can test on our end and see if we can reproduce the same behavior?


Since the app was deleted all associated files with the app were also deleted so performing root cause analysis would be impossible. 


The recommended workflow when failures occur is to recover the data from the device prior to troubleshooting that way a backup of the data has been maintained. 


Thank you, 




Thank you,
New Contributor II

Hi Zach.

Thanks for your reply!

And thanks for the explanation of the record count. Based on this, the record limit seems not to be the cause for the crash.

Yes, the species are repeats within each form. Further data (GPS position, mapping unit, date and time,…) were only registered once at each of the 44 locations.

Unfortunately, I don´t have access to the XLSform since the survey was created by one of our project partners.

We have already accepted that the data are lost for good. The desperate field worker was not aware that data get removed with a re-install.

Regarding the app crash, Philip answered on my identical post (I am really sorry for the double-post. The first one didn’t show up, neither in the forum nor in my profile). He mentioned a lack of memory on the tablet as possible reason. However, i think the tablet should have managed the amount of data.

Well, I realize that it will be difficult to figure out what happened now that all data are gone. Next time we will be more cautious with the backup.

Thank you so much for your help!

0 Kudos