Text calculation not updating in nested repeat

[KMo]

The first page of a data collection form has text fields for the plot name and phase (pre/post). Following the first page, each nested repeat contains a calculation field that concatenates the plot name and phase. This allows easier tracking of which repeat records belong to which plots when data is exported. 

When a user enters the plot name incorrectly, collects data, then corrects the mistake before submitting the form, the nested repeat records still contain the incorrect name. I tried calculationMode=always in the bind::esri:parameters column, and the first record of the nested repeat will update but subsequent records will not. We have up to 200 repeats in some forms. 

Is there a way to refresh all calculated text fields before submitting the form without scrolling through every nested repeat record? 

[DougBrowning]

No you would have to scroll through all repeats for the calculations to refire.  This is the same issue you posted yesterday.

For us we load all the plots into Field Maps and use launch links to pass over the PlotID and other config fields to 123.  We never let them edit the PlotID.  This was a big win for us since, as you say, the user enters wrong IDs a lot.  We even send the lat/long to the form and warn them if they seem far away from the plot they picked in Field Maps.  Field Maps allows the crews to have a actual map to find the locations.  More advanced workflow but its works well for us.

We still have some that sneak through and we have QA scripts that run to check for this.

You could also have your plot list be a csv with lat/longs in it and warn the user they are far away.

[MobiusSnake]

I don't have a Survey123 fix for this but this is how I get around it, since I have a similar issue - I have Plot IDs which need to be "cascaded" to records in the repeats.

I have a Status field on all the forms I submit which defaults to a value like "New" or 0, indicating they haven't been processed.  I have a scheduled notebook that runs a few times a day that identifies new submissions and uses Python to copy the Plot ID (and do other calculations) to the related records from the repeat.  It then sets the Status field to a different value, indicating it's already been processed.

I also do some validation at this point and raise errors in a dashboard if there are other issues with the submission, and if it fails hard I won't bump it up to the "processed" flag.  Users generally work in disconnected environments so some validation can only be performed once the submission's been sent in.

I used hosted feature layer views to prevent unprocessed/erroneous submissions from being visible to other users.