Issues with Field Map to Survey123 field app workflow with related table

[Tiff]

This is a workflow that we intend to implement for multiple projects so I would like to understand the best workflow for this and any best practices. Our data structure consists of: 1) Hosted feature layer (points) and 2) Related table for inspections with the GlobalID/GUID relationship. 

The workflow from Field Maps to the Survey123 web app (browser) is working with no issue. But our staff are occasionally in offline areas and may prefer the Survey123 field (mobile) app option. It took me a while to figure out URL parameters and how they differ between web and field app, but ultimately I was able to use this parameter following the item ID: &action=edit&q:globalId={GlobalID}. However, when Survey123 field app opens it does not work properly 100% of the time. Sometimes the Inbox needs to be refreshed, other times it won't open up the survey even after refreshing, and most concerning is that sometimes it will pre-populate the survey with the wrong information.

Additional question: I'm noticing a discrepancy between how domains - code/description show up in Survey123. Web App (browser) shows the description while Field App (mobile app) shows the code. This has been tricky in configuring conditional questions. Is this intentional/is there any further documentation on this?

Thank you.

[DougBrowning]

Are you adding inspections to a repeat inside the form?  What I do instead is each inspection is a form then all the editing issues go away.  One inspection, one form.  Works well to get the spatial side and all that.  You already have the parent point in a related table so why have 2 parents?

Unless I am reading this wrong?  I find its always better to not have someone be editing an old record.  Just have them collect a new form.  You can still have the relate from parent point to child inspection.  I would also caution against using GloblaID.  If you ever have to recover from backup or process into SDE later its a nightmare.  I always use meaningful keys.

Just an idea

[Tiff]

Your suggestion is what I was thinking might be the best option moving forward. The main reason why I have the parent included is so that it pulls all the necessary information for reference (like asset ID, type, etc.) AND so that they can update the "Last Inspection Date" in the parent as well.

But if I am understanding correctly, you mean have the form just include questions from the child/related table, right? And in that way, the URL parameters would be configured to pre-fill whichever fields from the child need to be brought over by the parent?

And yes I have definitely been considering the pros/cons of GlobalID especially if transferring the data elsewhere... I am sure that will come up someday.

[DougBrowning]

Yes you can pass over whatever fields you need from the parent for display in the form.  Last inspection date type things I use Arcade to look that up using featureset.

For more on globalid see my post here  https://community.esri.com/t5/arcgis-collector-questions/related-tables-for-offline-data-collection/...

Hope that helps

[Tiff]

Thanks! That was honestly an easy fix compared to all the other wrangling of URL parameters, spinning my head around why the previous workflow didn't work. That's how I'll approach it moving forward. 

Right now we're doing a workaround where the inspector can update the Last Inspection Date in Field Maps since they are working off of that already. Is there anything you've done in Arcade that could somehow automate it?

[DougBrowning]

You can only display the date with Arcade it is not a real field.  No Attribute rules in AGOL yet.  So you can display the last date in the popup and table but you cannot symbolize or filter on it.  Which is really the major bummer of arcade.  It looks pretty but since its not a real field it gets limited.

You could go old school and run a script each night.  Symbolizing by related records get asked all the time but they have no figured out the speed issue I think.  Some use joined views also.

[RhettZufelt]

Additional Answer:

Not sure about the answer to your question, but I learned long ago that ESRI products often treat code/description values differently, depending on what app, and what you are looking at in the app (popups, tables, etc)(they can't seem to settle on a 'standard').

Now, if I create a domain, the code and description are exactly the same.  No more issues......

R_

[Tiff]

Thanks for sharing! So you mean for your existing domains, you aren't seeing a difference between the two? The layer I am using actually has those domains set but the code/description discrepancy definitely shows up across the different apps!

[RhettZufelt]

I'm sure the 'discrepancy' is still often there, but since the code is same as description, it always shows the same value whether its showing code or description.

R_