Syncing Survey123 data to a versioned environment

[Anonymous User]

Background Info: Moving hydrant inspection relationship from FacilityID to FacilityID (hyd feature class to hyd inspection tbl) to anew GLOBALID to Rel_GUID relationship.

After doing some searching, it appears that in order for Survey123 to support an auto-generated ID (i.e. GUIDS) the feature service the survey is being published from cannot be versioned, in order to have applyeditswithGlobalIDs set to True. 

This means I would have to unregister as versioned the following: 

Hydrants, Hydrant Inspection table, Manholes, Manhole inspection table, meter assemblies/meter inspection tables.

Or, I could copy the data on SDE, unregister it, and maintain copies of datasets (want to avoid this if I can). Having the surveys as hosted feature services would present its own problems because then I'd have to manage two different related tables with different relationships. 

Bottom line is we want our field guys to have an autopopulating ID whenever they create a new feature, and have the relate based on that. This may be possible with an arcade expression, I am not sure. Any help is appreciated!

[DougBrowning]

If you already have points for these assets then you could have the existing FC in Collector.  Launch the 123 form from the popup and pass the asset id over to 123.  Then have a relationship class between them.  I prefer to not use globalid since you can't edit them, they can not be recreated like a pattern can, and it all breaks on export or a database move.

See my post here for more https://community.esri.com/thread/221263-mapping-with-survey123-within-a-polygon-or-admin-unit 

Hope that helps.

[Anonymous User]

Doug,

Thanks for the response. This would work fine, but the only problem is if say a field guy goes out to a job site where a brand new Backflow is being installed, or a hydrant, etc.. they collect a point in Collector and they'd either have to manually input an ID as a placeholder, or leave it null. As a result, it would be a lot harder to discern which hydrant the survey form was filled out for, unless we had an auto-populating ID.

Our existing workflow is this: 

CollectorFC sitting in a versioned environment based on a Field_Edits version

Inspection table sitting in an EGDB with a relationship based on facilityID. Our ID scheme is something like wFH and then a sequential number. I can set up a python script that calculates new ID's, but this won't happen in real time. 

The hosted FS gets downloaded into a staging GDB (not on SDE) and a script gets ran to add new records to the inspection table. I just see this being a problem if the crew puts in the wrong sequential ID, or if the sequence breaks. I thought basing the related table on a GUID would make this easier to manage, but perhaps not.

[DougBrowning · Accepted solution]

Best we could do is have a crew number as part of the ID.  We have a 5 digit number with the first 2 as the crew number and the next 3 as the code the crew can increment.  Does not have to be sequential across the DB just unique.  If we have 10 crews all offline then sequential is impossible.

Hope that helps.

[Kevin_MacLeod]

Is versioned data still not supported in 2024 in Survey123?   @KoryKramer  I am doing the very same thing. Hydrants and related inspection table. I wanted to have just one version for all data collection for a QC.  Versioning..well, I don't advise anyone to use more than one version with SDE.  It risks data loss. But with just one version parent to child, Differences pane seemed like a helpful QC. Plus although Archiving is not supported on children (nor comparing child to child, hence I advise using only one version) - because I was going to check in data weekly from the child, I figured the Archiving of that on Default would be good enough. 

Lack of support for versioned data on Survey123 is a curve ball.  Surprising it's not supported. There have been threads on here for close to a decade on this particular issue. Data collection is where GIS data begins. I know the focus has been 3d and now AI but field data collection is very profitable: it requires Enterprise licenses and Named Users.