Using Cascading Choice Lists in Survey123 Connect

[BrandonCranfield]

Hello all!

I am using cascading choice lists in my survey built in Connect (v3.20.63). Noticing some interesting behavior when publishing the survey to portal (v11.3). The feature layer treats the first choice list as a coded value domain, but all related subsequent choice lists are treated as text input fields. We need the subsequent lists to be treated as coded value domains as well in order for the modify/edit capability to present those fields with dropdown choice options. This is in an attempt to remove as much human error from the process as possible.

Any suggestions?

[abureaux]

• Publish from Connect without the cascade settings so that all select_one and select_multiple are treated the same. Then add it in afterwords.
• Publish from ArcPro with domains and then build the survey in Connect on top of that, adding cascades at that point.
• Don't edit directly in a web map, and instead use an embedded survey or other such process.

[abureaux]

Also, is there a reason you are using an outdated Connect?

[BrandonCranfield]

Apologies, fixed the version in the original post. 3.20.63. I will try out your suggestion and get back to you.

[RyanUthoff]

I'm using the latest version of Connect and can replicate the same behavior in 11.2. I'm assuming this behavior is by design, although it doesn't quite make sense because the question type in S123 is the exact same and should honor the domain. One possible reason for this is because S123 has the functionality to "filter" the domain by using cascading choices. Hosted feature services in Portal don't have that functionality, therefore everything will be visible even if it's not a "possible" value based on the cascading choice. And maybe Esri is being overly cautious and just doesn't apply the domain at all? I'm not sure.

Regardless, there is one workaround that I know of that you can implement. Manually add the domain to the hosted feature service in Portal. Unfortunately, it would mean maintaining a domain in two different places (S123 and the hosted feature service), but at least you would be able to have a domain in the hosted feature service to reduce human error.

[abureaux]

Ya, the two lists may be a good solution in this case.

[BrandonCranfield]

Hi Ryan, thanks for the reply! I had the same thoughts about the disparity between Connect and Web. I initially thought the functionality behind subtypes might be a good solution, but havent really tested that out. Kind of on a time crunch!