Survey123: prepopulate conditional field with URL from FieldMaps

[Anonymous User]

I want to prepopulate a conditional survey123 field with a field in field maps using a URL.

my URL: arcgis-survey123://?itemID=da51303530f44e0191c219c07a2a8c98&field:WorkStatus=Field&field:PlotNumber={st_cty_plt}

The field PlotNumber is conditional and is only shown if WorkStatus is 'Field'. The above URL will populate WorkStatus as Field and show PlotNumber, but PlotNumber is blank. 

I tested this by editing my survey in survey123 connect. When the PlotNumber is NOT conditional, the above URL populates both fields. 

How can I change my url so that it populates a conditional field? 

[DougBrowning · Accepted solution]

Yes the field has to be relevant at the start for it to populate.  One trick is to use the new hidden column instead and then it can get a value but hide if you need it.  Note it will still have the value though.

You could also maybe add a check for blank on your relevant.  

Another option is to pass into a dummy hidden field then calc in what you need.

Hope that helps

[Anonymous User]

This is a really slick solution, and thanks for the speedy response. I auto-populated a hidden field with the plot number {st-cty-plt} then calculated the actual conditional PlotNumber with the hidden field. Works Great. 

Genius! Thanks!

[DougBrowning]

Great.  Note if you set the bind esri column to null the dummy field will not be created in the service at all.  Keeps it cleaner.  I use a lot of calc fields like that.

See this post - its a great trick.  https://community.esri.com/t5/arcgis-survey123-questions/can-the-or-other-option-be-required/td-p/11... 

[Anonymous User]

Hi @Anonymous User,

If you are using the latest Survey123 3.14 release, there is currently a known issue with passing URL parameter values into fields that are relevant based on a question that also gets populated via the URL parameters. We have addressed this in the 3.14 March update, which will be available shortly to test via the Early Adopter Community.

However, as @DougBrowning points out, it is still best practice to pass the incoming values from URL parameters into hidden fields that do not contain relevant expressions, so that the value is always there. You can also make these fields null also to not include in feature layer when submitted. From those hidden fields you can reference the values in other fields using calculations etc. This is a much more effective approach and provides the robust solution.

Regards,

Phil.