Survey123 Inbox and bind::esri:fieldType null

[DataOfficer]

We have an issue where, when a user reviews their Inbox, fields where bind::esri:fieldType is set to null are returned as empty, rather than the value that was entered in the original survey. I can understand this behaviour may be expected, as the question is not stored in the feature service. However, the issue is that in the Inbox, where subsequent questions are required, the user cannot progress through the form (e.g. through repeats) to make the relevant edits without having to remember what they entered in those empty required fields and re-entering them. Is there a way around this, short of storing those fields in the feature service?

Thanks, Rob

James Tedrick

[JamesTedrick]

Hi Rob,

It sounds like there may be a few details missing from your description.  Why would a null value prevent subsequent required questions being filled in?

If this is a situation where a calculate or hidden (i.e., non-user editable) question is set to null and then is involved in logic that would prevent the form from being submitted, that could cause a problem.  You could account for the potential null value (say, by using the coalesce() function to provide a default value), make the field visible to the user so that they could update values, or revise the business logic to not prevent submission.

[DataOfficer]

Hi James Tedrick‌,

Apologies, I didn't word it particularly well. I will try and explain more clearly. The form in question is for submitting wildlife sightings.

As an example of the form design and workflow:

FIRST SUBMISSION: when the user first submits the form, they select a species from a select_one dropdown list. This is a required field. The Species field has bind::esri:fieldType set to null as there is a hidden field further on in the form, that coalesces the species chosen between the species dropdown, and an 'other' text field (in case the species is not in the list). Therefore the hidden coalesced field captures a single species entry, from two possible entry fields, with the two entry fields supplying the coalesced field not being stored in the feature service. Several other fields have choice_filters dependent upon the original species entry field.

USING THE INBOX: using the same example as above, because the Species field is not stored in the feature service, it appears blank in the inbox. Because it is a required field, the user must select an entry to (1) continue to the next repeat and (2) be able to submit the edited form.

There are multiple examples of this throughout our form, where a select_one dropdown and an 'other' field (both bind::esri:fieldType null fields) supply a hidden coalesced field.

Kind regards,
Rob

[JamesTedrick · Accepted solution]

Hi Rob,

Thanks for explaining.  A couple of thoughts:

- Will the user be changing the Species on subsequent edits?  If so, you may want to retain the value so that the coalesce() function can continue to work

- If the Species value is not edited, you may want to take a look at the pulldata('@property', 'mode') function that is in beta currently and being released with 3.10 - this would allow you to make the Species dropdown non-relevant when editing and instead present a note that displays what was previously entered.

[DataOfficer]

Hi James,
 - Some users may need to change Species on subsequent edits (e.g. after reviewing photos to verify species identification). Therefore I think as you (and Michael below) suggest, I will change the form design so that these fields are stored in the feature service.

- Unfortunately the link you have shared is not working for me but it looks like the relevant content is covered here. I can see how that could be useful for any fields that are not required during editing.

Many thanks,
Rob

[MichaelZatorsky]

I had a similar issue. I implemented the trick to store a value from a select_one and an 'other' field into a single field using the three-field approach - that is, the select_one and 'other' fields route to null, then you use a third hidden field calculated to use a selected value if it exists, else use what was types into 'other'.  Only the third field is stored in the database.   That works beautifully, until you create an 'Edit in Survey123' hyperlink.  When the record is reopened in Survey123 web app - as you have  found - the null fields are not populated so the web app has no idea what radio button to activate in the select_one and there is no content in the 'other' field either.  Since the hidden field is, well,hidden, the user has no idea what was selected previously.

My solution is to not use null,  I just store all three values.   Its managed redundancy.  Storage is cheap.  The user cannot see or change the important hidden value, app logic ensures that there is consistency and the GUI always has the data it needs.   

My metadata alerts the user that two fields need to be ignored, or hidden in popups.

[DataOfficer]

Thanks Michael. I was thinking along the same lines so it is useful to see that other people have done the same. 

[JamieLambert]

This is exactly why I suggested an Inbox configuration of a form.

I would like the ability to configure how the survey form looks when opened via the Inbox versus opened as a new survey form. I know I could create a new survey using the existing hosted feature, though users then need to remember that they have to go to a different survey for for some activity, which presents its own challenges! Something like an additional tab in the Survey123 connect xlsx spreadsheet that can be populated if the Inbox setting are different to the new survey settings?

Three examples:

1) I would like some fields to be read-only for editing workflows.

2) For Image questions that are required in the initial survey, make these not required via the Inbox.  

3) In a new survey, I often use Calculations to take user input, and write it out to other hidden fields.

Idea below: 

https://community.esri.com/t5/arcgis-survey123-ideas/configure-an-inbox-form-view-survey123-connect/...

[Anonymous User]

Hi @DataOfficer @JamieLambert @MichaelZatorsky,

Just letting you know we have recently updated the 3.14 beta builds on the Early Adopter Community and the next release will include major improvements to the expression calculation engine, new calculation modes, improvements to loading relevant questions and repeats, and other fixes to repeats, nested repeats and repeat count. With these improvements we see faster loading surveys, increased stability, less crashes and ability to optimize calculation workflows.

The issue you reported above will null field types and always running calculations can now be solved using the new calculation modes available in the latest 3.14 beta builds, where you can set calculations to always run, be manual or auto. We have seen this resolves many null field type calculations when using the Inbox.

Please refer to this blog post for more details: https://community.esri.com/t5/arcgis-survey123-blog/arcgis-survey123-3-14-beta-now-available-for/ba-...

Direct link to EAC announcement: https://earlyadopter.esri.com/project/article/item.html?cap=e69ef91f45744b98882c651f7b518eb7&arttype...

Regards,

Phil.