Using Survey123 form built on feature service

[Lwkrynock]

Hello All,

I have built a Survey123 form on top of a feature service to use for sewer manhole inspections following this post: https://community.esri.com/t5/arcgis-survey123-blog/working-with-existing-feature-services-in-arcgis...

The feature service references data in a SQL server sde gdb. The feature class and table are branch versioned. The relationship class is set up using parent "GlobalID" field (manholes) and child "guid" field (inspections table). 

The survey begins with 2 fields/questions from the manhole feature class and then uses a repeat to access the related inspection table. It is launched from a link configured in the webmap popup and is opened from ArcGIS Field Maps.

The survey form works as expected using the mobile FieldMaps and Survey123. The data entered for the inspection portion (repeat) is successfully populated in the inspection table.

I'm having an issue viewing viewing related data. While it appears that the relationship is maintained between the feature class and inspection table, I can't see related records in either the web map or accessing the sde data in Pro. I also noticed that the values populated in the guid field for the inspection table don't match the corresponding feature's GlobalID. The examples below were all entered for this same manhole point. 

This is what happens when I select show related records in the webmap:

My understanding is that since the survey is built on a feature service with the relationship class, I don't have to pass the GlobalID value to the guid field - although, I tried this anyway (through the inspection url) and it didn't work. I assume this is because the guid field is within the repeat. 

I have built a similar survey on a hosted feature layer with the same relationship/configuration and it works fine. 

Any help is appreciated! I am this close to moving the whole thing to field maps, but would really prefer to use Survey123 since I have a couple of multiple choice questions. 

Thanks!

[DougBrowning]

I use a lot of custom relationship classes but I also leave in the built in ones from 123.  I think that 123 will only automatically keep your related keys populated if you use the built in way with parentglobalid field in the child.  I will allow other relates to be in there but it is on you to keep them populated correctly.  That is why I use meaningful keys and not globalid so then I can calculate my child and parent keys easily and keep them in sync.  Plus if you ever export and import to something else like a GDB the globalid plan goes sideways.  123 team may know better if using a different relationship class is supported yet.

In your case I am actually not sure how to get the globalid of the parent inside the form.  If you have just the repeat in your form and not the parent (which I recommend) then you could pass the parent globalid over in a URL and give it to your key field in the child.

Field Maps will auto populate any child key it can find unless there are more than one relate I think it just does the first.  What we do is use Field Maps to navigate to the parent point then use a URL to launch 123 and add a child passing over the key.  That way we never have people editing and changing the parent.  I also always suggest to make the related inspection a feature class vs a table.  We have crews use the wrong parent on the regular and the map clearly shows they were somewhere else.

I just had to respond so I could say go NC State!   Hope that helps

[Lwkrynock]

Doug, 

Thanks, this is very helpful! I used many of your other comments on other threads when I was trying to figure out how to set this up in the first place! Are you a Wolfpack-er?

I'm going to remove the parent questions from the survey and just have the inspection/child questions (no repeat) and try out your workflow using the url to pass the key.

The only reason I had both parent and child fields in the survey is because I have a "material type" field that is in both. It is not always populated or correct in the parent features. What I was hoping to do was capture material in the parent and then pass that value to the child field. I know there are other workarounds but not sure of one that would automatically populate the child field based on the parent value during the survey itself. Maybe attribute rules could do this?  

Also good point about the child being a feature class. We have some surveys that aren't yet linked to features, and when I look at the Survey123 feature layers I've noticed that staff like to catch up on them when they're at home. 😆

[DougBrowning]

Are you a Wolfpack-er? - yep!

 Maybe attribute rules could do this?  In enterprise yes but not in AGOL hosted layers yet.  Arcade could display it.  Or map the children instead of the parents.  I just talked to the Arcade team on this there are ways to get close but hard to map a related attribute.