Using Field maps voor inspections with a protected default (branch versioning)
#TLDR Can you make a relationship between a branch versioned Featureclass and a non-versioned table and publish this as a Featureservice without version management extension for Field maps use?
We're currently migrating a system of record from the old Arcmap 10.8.1 to ArcGIS Pro and as part of this, we're implementing branch versioning for the new system.
Because it's our system of record and as a government some legal stuff is based on the assets, we've chosen to use a protected Default branch, which makes it possible to do a QA before the edits a posted to default.
Branch version scenarios—ArcGIS Pro | Documentation
For our GIS viewers, we are implementing a separate service based on Default which can be used by anyone to just view the data, like this:
(the above image was modified by me from the source docs to include both the Query only FS and the protected default branch)
Now to my question:
the implementation as described above is what we need for a well maintained system of record, with a careful review process. But it takes some time to get the edits from the named version back to the protected default.
This makes is less suitable for inspections on our assets where we want to see the inspection results without any delay.
Suppose we have a type of asset that gets inspected regularly. To allow for easy inspections, I would create a Table in my EGDB, enable attachments on this table and make a relationship to the asset. I would then publish a Featureservice, create a field map configuration, where I disable editing on the Featureclass and enable editing on the table and now my field workers can go out and do some inspections. However, when they try to do so, they will get an error message because field maps is trying to save the edits on default. Right now there is no option to create another version in Field Maps, other than creating an offline area and to do the inspections offline.
Creating different offline versions for the inspections creates another problem: it is hard to view all the inspections in real time on a ops dashboard and the people who are doing the inspections cannot see the data of their colleagues because they’re all working on different versions. To get all the inspections back to default we would either need somebody with Version management privilege in their role to post the inspections back to default, or an automated script which does the post to default.
So I don’t need the full QA process on my inspections, I don’t want to have versioning enabled on my inspections and attachments, but it looks like it is what ArcGIS expects when creating a relationship between the Featureclass and the Table. Because when I create the relationship, versioning is automatically applied to the table as well when versioning isn’t there yet. So this behavior makes me think this is how versioning is designed to work
Alternatives:
Disable versioning again on the inspections table
So I decided to disable the versioning on my inspections table, this is possible with a relationship. Then I created a mapservice and featureservice with editing enabled, but no version management server enabled. This makes it possible to edit and create new inspections directly on default.
Advantages:
- All inspections are visible to everyone in realtime, enabling a ops dashboard
- No post to default has to be done by a script of Version management user
Disadvantages
- The featureservice also allow to edit the Featureclass on the protected default directly.
- Doesn’t look like this is supported by esri
- You get warnings when publishing the service
This would look like this:
Use survey123 for collecting the inspections, with Field maps as a viewing application
This alternative does not use a relationship on the database level, instead a relate can be configured on the mapservice for viewing the results and a featureservice with standalone table can be used to edit or create new inspections using Survey123. Using hyperlinks in the popups in field maps, the user can open Survey123 and create a new inspection with the globalid of the Feature or update an existing survey: https://doc.arcgis.com/en/survey123/get-started/integrate-launchfieldapp.htm
Advantages:
- All inspections are visible to everyone in realtime, enabling a ops dashboard
- No post to default has to be done by a script of Version management user
- No direct editing on the Featureclass is possible so the field workers can only edit the inspections table
- Looks to be fully supported by Esri
Disadvantage:
- You will have to configure relate / magic links everywhere you want to view the inspections on the featureclass
sorry no image here, but you get the idea
I’m I missing something here? Any other thoughts? Would love to hear some feedback 🙏
