I have a survey published via Survey123 Connect, which contains several select_one questions. The questions are required and have no default answer/value set. When a user saves an incomplete survey to drafts and reopens the draft at a later stage, the survey is as is. The answered questions are unchanged as expected, and the unanswered questions are still blank.
The problem arises when the survey is saved as a draft a second time. When the user reopens the survey, the answered questions are still fine, but the unanswered select_one questions now default to "No". This is a challenge as "No" is still a valid answer and users are no longer certain where they stopped their capture.
Is there a work around to prevent this from happening?
- Published from ArcGIS Survey123 Connect 3.11.123
- ArcGIS Survey123 mobile app Android Version 3.12.277
- Attached sample survey
Thank you for passing along the XLSForm! I have tested and was able to reproduce the same behavior on my end. There's a couple of things going on, but ultimately is a defect on our end. What's happening is after saving the survey as a draft the fist time, on the back end only the questions where data was recorded is stored. The issue is after saving the survey in the drafts for the second time all the questions are then stored on the back end and the ones that aren't answered have a "null" value associated with them. Since the choice lists are 0 based when the survey is opened back up the Field App is mistaking those "null" values as "0" and selecting the choices.
The workaround that worked on my end was to switch the choice lists from 0 based to 1 based (ex. 1:No, 2:Yes, 3:N/A). The issue (other than needing to update the form logic with the updated choices) is it looks like the survey was created based on a feature service pointing to an Enterprise Geodatabase feature class. After republishing the survey the domains in the Enterprise Geodatabase feature class will also need to be updated to reflect these changes.
We have an internal issue for the defect logged on our end but unfortunately it doesn't look like an official Esri Support BUG has been logged for the behavior just yet. I would suggest creating a ticket with Esri Technical Support to have the defect logged which will make it easier to track the status of the issue.