Unanswered Select_one questions in Draft defaulting to "No" after second save

[Anonymous User]

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?

Environment:

- Published from ArcGIS Survey123 Connect 3.11.123

- ArcGIS Survey123 mobile app Android Version 3.12.277

- Attached sample survey

[ZacharySutherby]

Hello @Anonymous User,

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. 

Thank you, 

Zach

[KatherinePadilla]

I am having a similar issue with our non relevant number fields populating with 0 instead of null even if the default is set to null and the calculation states if not relevant set to null.

Do you have a BUG ticket for this issue?

Katie.

[ZacharySutherby]

Hello @KatherinePadilla, 

I don't see an official Esri Support BUG logged for the issue above. For your workflow are you seeing the issue when saving surveys to Drafts, or in general you see the issue? 

If possible would I be able to obtain a copy of the XLSForm and the steps to reproduce the behavior to investigate the behavior? 

Thank you, 

Zach

[KatherinePadilla]

Hello, Thanks for your reply! 

Here is the XLSForm.  This has been happening I think since we first started this survey 2/2019.  It is only when the survey is saved as draft.  If it is submitted right away there is no issue, all the expected fields get populated with Null.  I have tried setting the default to null as well and this yielded no success (see the Test Coastal Survey XLS).  I tried filling out the survey in different ways, answering the critical question (SD_FLOW_OBSERVED_TYPE) that determines those fields to be null or populated before and after saving as draft.  I think it must be the way that the survey loads after saving to drafts.

Note only the number fields populate with 0, the text fields, date/time fields etc populate Null as expected.

I have attached some of the tests I did and the result.  The yellow is the desired output.

Katie.

[KatherinePadilla]

Hello @ZacharySutherby I was wondering if you were able to take a look at this to see why when placed in draft the irrelevant numeric fields are populating 0 instead of <null>.

Thanks,

Katie.