Branch Versioning / Field Maps workflow

[JeffreyWarren]

I'm looking for ideas on workflows for using Field Maps & branch versioning.  A little back story: We just upgraded to enterprise and are moving everything to branch versioning.  Before our upgrade, we had several field workers making edits via collector, to AGOL hosted feature classes.  I would pull their edited data and combine locally with our gdb and then republish to AGOL afterwards.  I'd like for our field crews and everyone in our org. to see the latest data.  However, I do not want our field crews to be editing the default feature service, which as I understand, updates the sde data as well.  I would prefer to have the ability to perform some QA/QC before the live data is updated.  Is there a way to insert a QA/QC level on the field crews updates?   To throw a wrench in, I'd prefer to not force them to download the map in Field Maps.  Reason being, they may be on the north side of the city for 30 min. and then have to go to the south side for the next 2 hrs., etc.  Downloading the full city is a rather large dataset and a step that some of the guys...well, they are not the most technically saavy.  So, if anyone has any workflow ideas/suggestions to allow for QA/QC to be performed on Field Maps edited data, before it hits the default dataset, I would be very much appreciative!  Thanks in advance.

[JeffShaner]

Hi @Jeff - great question (and great name),

I'd like to comment from the perspective of our current, supported implementation of Field Maps but at the same time and very interested in hearing approaches others would see as viable (both connected and disconnected).

As you know, with branch versioning, you can only publish the default version - you cannot publish a version that you'd like to edit directly into. When creating a replica (downloading a map area to your device), the feature service will create a version for you and this doc topic describes it well.Even when working disconnected, branch versioning has only 1 level of depth off default to work with.

With ArcGIS Field Maps, we have a backlog item to support connected editing against a branch. We envision building this functionality so that the mobile worker does not need to understand or be faced with "versioning" in the UX. However with this capability missing, all edits will be stored directly into the DEFAULT version. I do not have an ETA on when we will implement connected branch versioning at this time unfortunately but it is in our short to mid-term road map.

What this means is that you need to consider:
1. Adding an attribute value to manage the state of a feature collected/edited in the field and filter all views where QA/QC has not been performed.
2. Use an alternate approach based upon the data collection/editing needs. For data collection/insert-only based workflows it could be a separate feature layer that is a repository for features that you then merge into your primary layer or perhaps you continue using AGOL and leverage distributed collaboration that is within 10.9.1.

Thank you for posting this question and please keep us updated as you progress!

[ChrisJensen]

So this means that Pro is the only ArcGIS client app that can edit a branch version that is not taken offline?

[JeffShaner]

@ChrisJensen Experience Builder supports switching branches now as well with the Branch Version Management widget.

[MatthewCriel]

Iam also looking forward to branch versioning in field maps , is there a ETA? Will it be available in the early adopter program soon?

[JoseSousa]

Hi @JeffShaner, I thought that field maps would comply with the settings set at the web map level? If we add a layer to the web map using the "gdbVersion" parameter, which is simply a pointer to the version we are looking for, my expectation is that when the layer is rendered in field maps, it should use this version instead of default.

https://community.esri.com/t5/arcgis-enterprise-questions/use-branch-version-in-map-viewer/m-p/11510...

You can easily test that querying a branch feature service with a gdbVersion other than default get's you results from the branch version not default.

But sure, the editing workflow is slightly different when you edit a branch version, as you have to start an editing operation, and undo's/redo's work a bit differently as well. But if this is already implemented, and what Field Maps does not have is the ability to switch between versions, then we could simply create a branch version in advance called "qa_qc" and edit the web map layers to use this version instead of default through the gdbVersion parameter. Field Maps could just accept this as being valid.

[BenRomlein]

I'm also waiting on this feature.

I tested the workflow from @JoseSousa and I could successfully create a web map in Portal that pulled data from a named version, but when I connected to this map in Field Maps, data was pulled from Default and all edits went directly to Default.

Anyone getting different results? If not, I'll probably go with one of the two workarounds proposed in the original reply.

[JeffreyWarren]

We are opting to have an attribute of QAQC and default is 'N'.  Field crews can't edit this nor even see it.  Just on my end so I know what has been added.  As far as data that has been updated and not added, I sort by last updated to find those edits.  Typically, that is just attribution edits which isn't a big concern since majority of our attributes are set via domains.

[D_AnneHammond]

Any esri update on this since July 2022? 

[PierreloupDucroix]

I understand from the discussion that we still don't have a solution to edit a named version in the field. It means that in a desktop / field / desktop / field workflow, we have to automatically or manually manage field values representing the state of every feature edited in a way or another... Or to add alternate feature layers and manage sync between them and our database...

I hope solutions will be found, at least, to persist a webmap's gdbversion parameter in Field Maps, to view or edit a specific version online. Or better, to be able to take offline a named version.