Editing existing record in Survey123 - Update Date only when submitting new related record

[ZachWasp]

Hello,

I have created a Survey through Connect to open and edit an existing point feature by passing the GlobalID with URL parameters in a Web Map Pop-up.  The workflow I am trying to accomplish is as follows:

- Select an existing asset on the map where you are performing a task for said asset
- Click the generated link in the Pop-up with URL parameters to open Survey123 app for said asset
- Survey123 form shows some of the fields for the parent asset and allows you to create a new related record for the current task.
- Submit form and update fields on the point layer, submit new related record.

I have got it working where I can open the record in Survey123 and manually update the fields and create the new record, but I am running into issues when trying to maintain/update a date field on the parent (point) layer.  I have a date field for "Last_Inspected" that has an existing date when the last related record was submitted.  I want the survey to preserve that date, unless a new record is submitted, which I tried to accomplish with the 'indexed-repeat()' function.  However, this will delete the existing data when there is no new repeat record created, which is a problem since I need the users to be able to submit the survey even if they don't create a new related record (unable to perform the task).  I tried to store the existing date in a NULL field on the survey using the 'Once()' function and do an 'If()' calculation on the date field but then that creates a circular reference in the table.  I also tried to use URL parameters to store the existing date in NULL field from the pop-up, but I am unable to prepopulate any fields using the URL parameter '&field:field_name={Field}' - I am unsure if this is a bug, an error on my part, or due to the fact that I am editing an existing record that it will not pass any fields through the URL (I also tested with a 2 text fields in case there was some unexpected behavior with the dates). 

I am at my wits end and I feel like I am so close to a solution to my workflow but I cannot figure out what I am doing wrong, or if there is another way to these dates to work how I need them to.  Any and all suggestions are appreciated.

Thank you,
Zach

[abureaux]

So they can submit to the feature layer, but that submission doesn't have to include a related record?

I would have a container within the survey to hold the previous date, and then have a separate calculate always override the old date with a calculate:

• Old date drops into the container via web URL
• A second field, a calculate, is set up with coalesce() to compare your old date with a third field: the logic calculate
• The logic calculate looks for new related tables. If none, it's empty. If one is found, then use today's date: today()
• Back to the second field, your calculate could look like: coalesce(${new_date},${old_date}). With this set-up, your coalesce() will either default to old_date if there is nothing in the new_date field.

Thus, you end up always entering in a date, but that date will only be updated if you add a related table.

[ChristopherCounsell]

I don't think this works with Inbox as it'll create calculation loops and custom url parameters for field values aren't supported.

[abureaux]

Are you talking about doing this all inside a repeat? I was assuming this value was calculated outside the repeat. That’s the only way I see  this making sense as we are talking about cases where the use submits without a related record.  

[ZachWasp]

That's exactly what I tried to set up, however the URL parameter to pass the field does not work for some reason.  I should say I am fairly new to Survey123 so I am unsure if this is a known limitation or I am doing something wrong.  It is able to execute the URL query for the GlobalID since it opens the correct record for the selected object.  Here is my dynamic link with my itemID removed:

https://survey123.arcgis.app?itemID=_____&field:hold_lastflush={hyd_lastflush}&q:globalId={GlobalID}...

[ChristopherCounsell]

It doesn't work. I've been down this path. 

https://community.esri.com/t5/arcgis-survey123-ideas/support-url-custom-url-field-parameter-for/idi-...

I can find an enh/bug number later

@IsmaelChivite FYI - would be good if the documentation was updated or support introduced 

[ChristopherCounsell · Accepted solution]

I've looked into this extensively. Inbox is great but am also moving to adds only with Notebook logic to update parent. Solves issues with offline workflows, editing permissions.

But with Inbox I would recommend avoiding heavy logic and interaction working within repeats, if possible. Leads to complexity and calculation loops.

What you can do is setup a null question in the survey to apply relevancy to the entire repeat and the last updated field.

Step 1: Set a repeat_count of 1 on the repeat so if it is shown, they can only submit one record. It'll look like a group to end users. Don't bring down existing repeat records; these can be viewed in the map pop-up. Solves a lot of editing issues.

Step 2: Add a null yes/no style question e.g. "are you doing an inspection"

Step 3: apply relevancy to the entire repeat based on the yes/no question

Step 4: apply relevancy to the last updated date question also based on the yes/no question. Set to read only and add date calculation. Hidden appearance if desired. The set calculation mode to always in bind parameters. This means it'll always calculate with a new date, but only if relevant, i.e. the inspection and repeat is added.

Alternatively allow parent updates in field maps or a different survey, then have the logic inferred for this survey.

Custom url schemes for Inbox don't support field/value parameters. I believe I submitted an ArcGIS Idea for this...

[ZachWasp]

Thank you for the insight.  I was worried the answer was going to be that it was a known limitation.

I'm going to try and test out the revised setup you outlined.

[ZachWasp]

Firstly, I just want to thank you so much for your response to my post.  I was scratching my head at this for days.

I tested your setup and I think this will be usable for my workflow, although I do see some undesirable behavior regarding step 4.

I set my 'DATE' field to read-only, and applied relevancy based on a Null yes/no question as you suggested, which looks like so in the xlsform:
relevant: ${Record_Check}='yes'
bind::esri:parameters: calculationMode=always
calculation: indexed-repeat(${Inspect_Date},${Asset_Inspection},1)

This works exactly as intended when adding a new record, but the undesirable effect I noticed is if a user were to check the 'YES' in the Null field, and then switch to 'NO' this clears the stored date in the 'DATE' field and will overwrite it with a null value when submitting the survey.  At the end of the day, I can probably live with this behavior as it should only happen when a user accidently clicks the 'YES' button.

Please let me know if you see any error in my setup and if you have any suggestions.

[ChristopherCounsell]

If you have a repeat count of 1 you don't need the indexed bit.

It looks like you're correct - this is the way the relevant expressions work in Inbox. Works fine collecting data but obvious issues with calculations and Inbox. Not something I considered as we always get a repeat and calculate.

https://community.esri.com/t5/arcgis-survey123-blog/survey123-tricks-of-the-trade-hidden-relevant-an...

It's one of the reasons why I mentioned taking a different workflow, like edit feature in field maps, add related records with survey targeting related layer, and an automated process to update such as notebooks.