Hello,
We are trying to set up a Survey 123 based app where users will enter their data in a Survey form embedded in an Experience Builder App. The Survey 123 components are being built in Survey 123 Connect. The users will be able to edit their entries in a survey form in that same app. One critical component to this app is creating and maintaining a unique id that stays the same throughout the lifespan of the record, even if it's edited. This unique id is generated through a javascript function on a calculated field. This is a tricky process since every time the record is edited, all the calculated fields are recalculated, which causes the unique id function to rerun. I found a workaround for new surveys where I can use the datetime stamp in the survey start field to feed into a javascript function and write the logic to keep the same unique id if a record with that same timestamp already exists.
The kicker is that I am trying to import data from another system into this for already open cases. For these imported records I'm manually entering the date into the survey start field directly on the feature service. What I'm finding is that the XML field calculations cannot read the manually entered dates on the survey start field. It can read other manually entered dates on other date fields and it can read the dates autogenerated by Survey 123, but not the dates on these imported records. I had been operating on the assumption that the system would be agnostic to how the date data got inputted into the start survey field on the feature service, but apparently that's not true. Does anyone have any ideas on how to manipulate this data to achieve the same response?
