Generate unique ID on repeats that don't change

[JoeWaters1]

Is there a way to assign unique IDs to each repeat created during a session and not have those ID's change in the future?

I am trying to generate a unique ID with the uuid() calculation inside a repeat. I want each repeat to have a unique UUID AND I don't want the UUID to change once the survey has been submitted and re-opened.

I am struggling to get both requirements met. If I set the unique ID column calculation to uuid(), then each repeat gets a unique value, but the repeat's UUID change every time the submitted survey is opened in the future. If I set the calculation to once(uuid()), then all repeats get the same UUID during that session.

This workflow will always be preformed from a webform.

Survey123 Connect version 3.12

[IsmaelChivite]

Hi. If you add uuid() into the calculation of a question within your repeat, a unique id will be created for every record in your repeat. This value will not change (the calculation will not be triggered) when you reload the data into the survey.

You say: but the repeat's UUID change every time the submitted survey is opened in the future.  Can you provide steps to reproduce that behavior?

[JoeWaters1]

Thanks for the reply. Does hiding the field affect the functionality of calculations?

After some additional testing, I seem to only run into the issue of duplicate keys if I have the UUID field hidden, and not set to the text data type (I have a unique index on the field to be used in a reconciliation process later):

Once I set the data type to text (read only) and republished, I am seeing the UUID field behave as expected- meaning I get a unique ID on each record, and they don't change when the survey is submitted and re-opened.

Here is a rough outline of the intended workflow:

1) A user will click on a polygon in a webapp and follow a link to the survey (always editing existing records):

https://survey123.arcgis.com/share/[surveyid]?mode=edit&globalId={globalID}&version=latest

2) They will click the repeat plus icon to add a repeat and fill out the survey, then submit. 

3) Sometimes a user might need to go back and modify the responses of an existing repeat, so they will follow the hyperlink again and update something. They might do this for one or more repeats.

[IsmaelChivite · Accepted solution]

I see. I would definitively make the field as text and do not apply a unique constraint in the database.  Please make sure that the target field where you will store the value is also a text field type. If you keep the field hidden in the form, users will not be able to change the value manually and the ID will not change when survey sends the data.  I think your workflow will work well as you describe it.  Just make sure you treat your ID as text.  The visibility of the field does not explain the unique constraint message you are getting. That is caused by a constraint in your database that you want to remove.

On top of the ID you create with Survey123, you can also rely on the OBJECTID and GLOBALID values that ArcGIS automatically creates for you. If you use the OBJECTID and GLOBALID you will need to be careful if you copy your data around, as those values may be recalculated.

[JoeWaters1]

I was trying to use the ArcGIS for Python api append() method for backing up my data to a historical copy. I was struggling to use the GLOBALID as the upsert matching field- though I can't specifically remember what the issue was. I created a SurveyID field to manage my own unique ID that would match in both the survey and the historical copy. The upsert argument required a field with a unique index, so I added the SurveyID_Index.

I will set the data type to text and read only on my unique ID field and let the users know to ignore that field.

I appreciate all your help.