Is there a way to identify or calculate if a record has yet to be submitted?

Question

I have a Survey123 form where I'd like certain fields to be read-only when a record is brought back in the inbox (so they are only editable when a user creates a brand new record).  I've done this before by adding the ObjectID in as a null field and making the field read-only if string-length(${objectid})>0 (new records not getting a ObjectId until they've been submitted).

In my current form this won't work as I have two repeats and I'd like certain fields in both of these to be read-only.  I can put in an ObjectId field for both and it works (even though they are named the same), but the string-length(${objectid})>0 bit won't work S123 can't differentiate between them.

Is there a different way where I can calculate if a record in either repeat has yet to be submitted? Or is there a way to label the ObjectID fields so that the form can deal with them separately?

Any help would be greatly appreciated.

ChristopherCounsell · Answer

I would recommend taking the logic out of survey123 and not allowing users
to edit past records unnecessarily.

You can use custom urls, multiple tables and scheduled ArcGIS notebooks to
better effect.

E.g. create works with complete=no, custom url using arcade featuresets in
popup, launch survey to complete works, Notebook to post process it and
mark works as complete.

Or survey > add related record > notebook to process new related records
and update asset.

This lets you follow data collection more securely while opening up to more
powerful workflows. Pushing survey123 forms to their limits or less
documented / supported workflows leaves you exposed to survey124 updates
that break your forms.

ColinCampbell1 · Answer

Unfortunately I don't think that will work in my use case.  The process I'm trying to support is recording inspections and work carried out on hazardous trees.  The tree (its location and attributes) is the parent record and each tree can have multiple inspections and work action records linked to it (each of these is a separate repeat).  Parts of these records are entered in the field on one day but then need updating later on.  Some details need to be un-editable once they've been recorded to prevent loss of the original entry in the audit trail.  So, for instance, someone might enter that a tree needs a branch removing, then in the future they need to be able to amend that record in the field to say they have carried out the work (and when).  The original description of work required mustn't be edited (either intentionally or accidentally) but some fields can be (like when the work was completed).  So allowUpdates=false wouldn't do the trick - and neither would having separate forms as the fieldworker needs to access everything relating to each tree all at once in as easy a way as possible.

ChristopherCounsell · Answer

Can you share more of your workflow?

I find that when you take the path of multiple workaround approaches to achieve the goal you can get stung when behaviours change or you need to make casual adjustments (like adding a second repeat). In anticipation of these scenarios I generally recommend sticking more to established workflows, or possibly a different one altogether like Josh is saying.

At face value if you want to prevent users from editing existing repeat records I would recommend adding the esri bind parameter to the repeat:

* allowUpdates=false query

This lets you see previously submitted repeat entries whilst preventing the user from editing ANY of the fields, while also letting you capture new repeat data. Would this work for your scenario or do you want to control specific fields across new and existing repeats?