Our Public Works Department would like create an Asset Inspection workflow using Collector and Survey123. The idea is to view the asset on the map in Collector, tap on it, and be able to edit existing attributes if needed. In addition, there would also be an embedded Survey123 URL in the pop-up that would open a Survey123 form with questions related to asset inspections. Once an inspection has been submitted, we would like to view past inspection records by clicking on the asset in Collector and viewing the related records. The goal is to have the inspection related to the feature and not have a new feature created with every inspection.
I have set up a secured feature service with both the features to be inspected and an empty related table for inspections that are being related with GlobalID and GUID. I created a survey in Connect using the feature service as a template and set the survey submission URL to read a secured feature service that passes through AGOL (with credentials stored) from our ArcGIS Server.
Next, I open the survey from the pop-up in Collector (using the custom URL scheme) and fill out the form in Survey123. The problem I’m running into is when I submit the survey, it’s not just going into the related table, but it’s also creating a new feature in the feature class. I just want the inspection to be a related record to the asset I’m inspecting and not create a whole new feature for each survey. Is there a way I can set up this workflow so that each inspection (survey) is related to the asset I’m inspecting without creating a new point?
Thank you for the reference to that blog post. It does look like that could work for me. However, I noticed that in your example you are using Hosted Feature Services. Have you implemented this workflow using feature services coming from a non-federated ArcGIS Server? Do you know if the workflow would still be the same?
Also, in step #3 ("Create a new GDB in catalog - this holds your collector features"), can I just use an existing SDE GDB? I would rather not create a new GDB and use the existing SDE GDB where all of my data is housed. Could I just copy the Survey123 FC to that GDB and create the Relationship class in there? The only other step I would want to change is #8 ("Publish this gdb as a service") - I do not want to publish the entire GDB as a service. I would just want to publish the FC with the related table. Would this still work with the workflow you described?
Thanks for your help!
Yes it should work against a arcserver all the same.
Yes add the 123 FC and create the RC in the SDE (enough acronyms for you). I think you could publish without the parent layer. Not really sure why you would want that but i do not know your workflow.
In the end all you are doing is creating a relationship between 2 layers then repointing 123 form to this new spot.
hope it helps you we have several groups doing it this way now.
Hello Stephanie, I have many of the same goals as you do in this post, and am wondering how implementing this work around has gone for you. We have an SQL database and prefer to avoid hosted feature services in preference for features services so that updates are sent directly back to our SQL instead of being kept in the portal. Like you, I am trying to build a workflow that allows field crews to collect electrical distribution asset inventory information (Utility Pole Features and it's related table components like risers, crossarms, etc.) in Collector, then open a survey form built from the same feature service (that contains the Utility Pole feature class and all related component & inspection tables) to do all inspections.
Unfortunately, upon upload, we see the similar behavior where survey creates an entirely empty inventory feature in the same location on top of the collector feature and our inspections are not going back to the feature added using collector, but the feature created by survey, requiring post process joining.
Have you had any success with passing GUID keys to overcome this? Would love to hear as ESRI Tech support has told me that post process joining is the "only option for sending inspection table field updates back to features added or updated in collector."
I have done exactly this and it works well.
1- create geographic feature service (point, line or polygon) with GlobalID in an SQL server SDE database
2- create table and 1-N relationship class between FS and table (GlobalID <-> GUID)
3- ensure FS and table have Archiving enabled (or versioned)
4- Open in AGPro and publish as a Feature Service (non hosted)
5- In Survey Connect, use the URL of your FS as Submission URL and name of the table as Form_ID in the settings sheet (be careful, the submission URL should be like https://your_organization/argis/sharing/rest/content/items/*****item_id****) -- Do NOT add a geopoint question in your survey (unless you created a relationship class between two geographic layers) -- also DO NOT create the survey from your FS. Create it from scratch or it will show every field from your FS and related table.
6- ensure you have the GUID field in Survey123 filled with the GlobalID of your asset via the custom URL scheme (see how to use parameters here : https://community.esri.com/groups/survey123/blog/2016/07/30/understanding-survey123s-custom-url-sche... )
So far it works for me.
I have been trying to implement pretty much the same workflow you described above, but between a polygon feature service (parent) and a point (child) that I want to be created in Survey123, NOT Collector. I have gotten it to work such that when they click the custom url in Collector, data is populated into the survey, but when I go back to Collector and look at the relationship tables, the child knows it is related to the parent but the parent does not know it is related to the child. I thought this might have to do with the Notification setting for the Relationship Class, but I checked and the setting is set to "Both,
so I'm not quite sure what I am doing wrong here. Any suggestions would be appreciated.
Nice work, seems you are close.
Is the relationship a simple or composite?
My guess is even though you have “Both” setting selected, you may have chosen a simple rather then composite RC. Simple requires more programming to have the same effects as composites.
Let me know and we can go from there.
Get Outlook for iOS<https://aka.ms/o0ukef>
I use simple with no issues. Be very careful with Compostie. It will Delete any children the second you delete a parent. This makes data fixes very difficult to scary.
I do not think this is you issue.