Creating and Editing Against a Related Table in Survey123 with a Relationship Based on a non-GUID field

[BethanyBalisky]

Is it possible to edit against a table that is related to a feature class by a relationship based on a non-GUID field (i.e. Address field)? I have been looking at various questions/resources on GeoNet & other Esri documentation to find the best way to do this but have yet to find a solution.

The main clue I have found is that to create and publish a survey on Survey123 on an existing service that has a relationship (shows up as a related table in Survey123) and to use that survey for editing against a the table, the relationship has to be based only a GUID?

What if I cannot use a GUID? I have one location with multiple permits associated with that one location (related based on an Address field) which I want to fill in questions on Survey123 on each permit record.

[DougBrowning]

Yep I do just that now with 9 forms all connected to one master Feature Class.  See my full write up on how to do this here  https://community.esri.com/thread/221263-mapping-with-survey123-within-a-polygon-or-admin-unit

Hope it helps

[BethanyBalisky]

Doug,

I came across that workflow from some other blog post too, but the workflow begins with publishing a new Survey123 form/feature service. But need to create one based on an existing feature class (point layer with relationship class to a table of pre-populated content) and then add a few fields to edit on within the related table.

[DougBrowning]

Just create form from the FS then.  Rest works.

[BethanyBalisky]

That's the trouble. I did just that. Create the Survey using the existing feature service and (as in your first step) tried to publish. But publishing was not successful as the relationship was based not on a GUID so getting passed the first step was not possible...

[RobBlash]

Bethany what is the error you receive? I have a workflow set up as you described (S123 publishing to a related table in an existing hosted feature service based on a string, not a GUID). The caveat is that you need to verify the "supportsApplyEditsWithGlobalIds" parameter in the hosted feature service is equal to true (view the HFS JSON and search for that parameter).

The easiest way to make sure this happens is by enabling sync when you publish the HFS (and leave it enabled even if you don't plan top sync, because disabling can trigger a bug).

I would suggest you find a way to use GlobalIDs to avoid any future issues. You can add GLobalIDs to your esixting data, then use the address to create a lookup to rebuild the relationship.