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

[ColinCampbell1]

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.

[jcarlson]

I think you want pulldata("@property", 'mode')? That will differentiate between a new add and an existing edit.

[ColinCampbell1]

Thanks Josh, that's almost exactly what I need, but it doesn't seem to work for the related records in my form. When I bring back an (existing) record from the Inbox and go to add a new record to one of the repeats it gives the value of 'edit' rather than 'new' for the newly added repeat record. Does the pulldata("@property", 'mode') pull the value for the parent record only?

[jcarlson]

Ah yeah, it's for the parent record.

I don't know what your workflow looks like, but can you create a separate form that submits to the related table directly? We've got a few Field Maps and Dashboards that do this, where the parent feature popup has a link for "add new [related record]", in addition to the "edit existing records" form. The link for the new record form prepopulates the GUID of the parent feature, so that the relationship between features is maintained, but then the form can perform specific logic that we don't want applied to existing things.

[ChristopherCounsell]

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?

[ColinCampbell1]

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]

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.