Survey123 Related Table- incorrect Parent GUID

671
9
04-22-2019 12:09 PM
Highlighted
Occasional Contributor

I have an ArcGIS Online Feature service with a related table. The relate uses GlobalID in the parent and a GUID field in the table called Parent_GID.

We use Collector to get the point geometry, then a custom URL scheme to open Survey123 and collect attributes into the related table. The URL scheme is supposed to pass the Global ID into the Parent_GID field, but I'm finding that the wrong Global ID is being recorded. As a test, I set up a new text field in the Related table and when I send the Global ID to that field it records it correctly.

I'm wondering if the GUID field type is messing with the workflow? Its like a new Global ID is being created in the parent for the related record. There doesn't appear to be a way to create a relationship class in Pro that uses the Global ID from the parent and something other than a GUID field type in the related table.

Point as recorded with Collector:

Note the Global ID created with the point

Related Table populated in Survey123:

The Parent Global ID field above is the GUID field in the related table, the Point Global ID is a text field to which I am also passing the Global ID. Notice it's correct in the text field at the far right.

Collector is passing the GlobalID into a hidden field in the Survey123 xls called INCOMMING_GLID, then its being applied to both the esriFieldTypeGUID and esriFieldTypeString fields shown above via a calculation...

9 Replies
Highlighted
Esri Esteemed Contributor

Hi Aaron,

Can you provide the JSON version of the Service URL for both parent and related tables?  Is the parent GUID GUID field hidden?  If so, could you make it a note field to view the behavior in the form?

Reply
0 Kudos
Highlighted
Occasional Contributor

Hi James.

Parent: https://services1.arcgis.com/jIQJu4VdaCSXCq81/arcgis/rest/services/NRI_PT/FeatureServer/0?f=pjson&to...

Related Table: https://services1.arcgis.com/jIQJu4VdaCSXCq81/arcgis/rest/services/NRI_PT/FeatureServer/1?f=pjson&to...

There is another related table that I haven't tested, but assume it would have the same issue. https://services1.arcgis.com/jIQJu4VdaCSXCq81/arcgis/rest/services/NRI_PT/FeatureServer/2?f=pjson&to...

Parent_GID is hidden in the form- not at my office computer right now to change to a note and test, but I can try it tomorrow.

Thanks for any insight!

Aaron

Reply
0 Kudos
Highlighted
Occasional Contributor

I've confirmed the following by changing the Parent_GID field to note:

The correct Parent GUID is being passed to the Survey123 survey, and it's populating the survey fields correctly- both the incoming GID and the value entered into the Parent_GID field match the Global ID in the Collector point. However, sometime during or after submitting the survey the Parent_GID field in the related table that the survey references is changed. If I opt to send later, I can reopen the survey and still see the correct Parent GID. If, after sending, I then attempt to edit from the Sent box, the incoming GID (not bound to field) is correct, but the GID stored in the Parent_GID field has changed.

I think the related table must be overwriting the Parent_GID field on saving to the server. This totally breaks the ability to edit related tables with Survey123.

By the way, I am passing the Global ID using the calculation formula and instructions in this thread: https://community.esri.com/thread/208613-pass-global-id-from-collector-to-g.

if(regex(${INCOMING_GLID}, '^\{[\w\-]*\}$'), substr(${INCOMING_GLID},1, string-length(${INCOMING_GLID}) - 1), ${INCOMING_GLID})

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Hi Aaron,

I've attempted to duplicate your scenario you are describing, but I'm seeing the related GUID be properly set.  As I mentioned, the workaround with the INCOMING_GUID is no longer necessary- this was addressed in 3.1.

Reply
0 Kudos
Highlighted
Occasional Contributor

Sorry, I can't find where it was mentioned that the Incoming_GUID workaround is not necessary...does that mean I should now be able to pass the parent global ID directly to the Parent_GID (GID field type) in the related table via url parameter? 

Just to confirm- with your test, the Parent_GID stays put the same sending the survey? Mine is correct- UNTIL after its been submitted. When I look at the updated table, the Parent_GID field is no longer what it was in the form.

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Hi Aaron,

It wasn't mentioned explicitly in the thread, but the issue that led to the need to have the check for curly braces was resolved at release 3.0.  

Yes, in my test sample, the parent_guid was successfully kept through the submission process, with the records properly being related.

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Hi Aaron,

Thanks for sharing the web map and form design.  The issue is that you still have the repeat structure in the form - Survey123 doesn't support populating data into repeats and I wouldn't necessarily expect the parentglobalid to work properly in that context.  As the only parts of the 'parent' form are notes, you can remove teh begin repeat/end repeat statements and point the form_id to the related table - that is how a form targeting just the related table should be set up.  It also looks like one of the fields in the URL has the 'field' keyword twice

Reply
0 Kudos
Highlighted
New Contributor II

Hi James,

When I follow the steps outlined above, I get the Global ID passed in windows but not iOS. On the desktop app the Global ID shows in both the note and esriFieldTypeGUID field. Any reason it's not passing in iOS?

Reply
0 Kudos
Highlighted
Esri Esteemed Contributor

Hi Zachary,

Are you using Collector to open Survey123 and pass the attributes?  If so, could you provide more details on the pop-up configuration?

Reply
0 Kudos