I used Survey123 Connect to prepare a form for residents to submit their complaints. For tracking purposes (both internal and for the public) I would like to automatically generate a number. Nothing complicated, - just the year followed by the next number in the sequence (e.g. 2025-1).
I am using the pulldata query described here. I have confirmed that the feature layer is editable and supports query. I just cannot get it to work!
What am I doing wrong?
Thanks!
Solved! Go to Solution.
Not sure what you are doing wrong, but can I suggest an alternative? There are issues with using that method for making a unique ID, namely if 2 people are submitting at the same time, it is possible they generate the same ID. The preferred method is to incorporate the now() function and concat what ever pre- or post-fix you want, it is not necessarily pretty but it avoids the issue of multiple "unique ids".
Thank you so much @Neal_t_k. After having spent almost 3 days trying to calculate a ticket number using the method in the link, your suggestions are godsend.
I went with this format
I am so glad I came across this workflow because I have been trying to figure out this same problem the past few days.
However, have you had any issue with the "Ticket Number" changing and/or updating when the form is reopened or edited in the app and the web? Looks as though the ticket number updates to the most current date/time when opened/edited in both the app and through the Survey123 webpage. Hopefully there is a solution for the ticket number not to update when the form is edited.
I am so glad I came across this workflow because I have been trying to figure out this same problem the past few days.
However, have you had any issue with the "Ticket Number" changing and/or updating when the form is reopened or edited in the app and the web? Looks as though the ticket number updates to the most current date/time when opened/edited in both the app and through the Survey123 webpage. Hopefully there is a solution for the ticket number not to update when the form is edited.
In that case instead of now() you could use a required user input date and pull that field into the calculation. That still would change upon user change but it won't change automatically upon reopen. You could also play with the calculation modes and see if any of those work to remedy that situation.
I wonder if you could also play with the "start" question type, I don't know if that recalculates on reopen or if it remains the original start date and time, but it could be worth a shot.
the other option is uuid(), Those are kind of not pretty, though.
https://community.esri.com/t5/arcgis-survey123-questions/survey123-unique-id/td-p/815617
@JordanHyche_MCI I used this in the calculation field for datetime so that it does not change to the most current date/time when opened/edited: once(now())