ArcGIS Pro

QA/QC workflow with branch versioned data

A common question that comes up for users that are moving to branch versioning is how do I perform the same types of QA/QC workflows that I’m used to doing with traditional versioning? Branch versioning’s flat, one-tiered version tree does not allow for an intermediate QA version, so what is the alternative work around? Let’s discuss how the same type of QA/QC workflow can be accomplished through the process of transferring version ownership, adding a note in the version description, and changing the version access type.

 

Let’s look at a common traditional versioning workflow

Traditional versioning workflow diagram
Traditional versioning workflow diagram

In this scenario, a medical organization is using traditional versioning in their GIS department to isolate edits from individual work orders performed on the ground by the field editors. The default version is set to protected, and the field editors’ versions are reconciled and posted to their parent QA version. Next, the geodatabase administrator will reconcile and post to default. The goal of the intermediate QA version is to allow a supervisor to perform QA/QC on the data before anything gets pushed to Default where the information becomes publicly available to viewers. The supervisor in this scenario is the geodatabase administrator.

 

How would the above workflow look with branch versioning?

With branch versioning there is no intermediate version in the version hierarchy. This versioning type only supports a single level of versions below default to simplify version administration. However, you can adopt the same QA/QC framework by using a combination of version properties such as version ownership, version description, and version access type. Also, you’ll notice that most of the higher-level version management tasks (such as posting to a protected default version) will also be performed by a portal user that we refer to as the version administrator.

Branch versioning workflow diagram
Branch versioning workflow diagram

Let’s test it out!

The following short workflow scenario shows how the use of version properties will give you a similar QA/QC experience with branch versioned data.

 

New work order received by the field editor

A new work order comes in for Bedford Alzheimer’s Care Center in Hattiesburg, Mississippi. The following details of the property need to be updated:

This work order has been assigned to Jack Groome, an editor in the region who went on scene and confirmed the validity of the above details. Now he will make edits to his organization’s branch versioned data to reflect these changes.

The editor (jgroome) connects to his organizational portal in ArcGIS Pro, adds the Medical Services web feature layer to a new map, and creates a new version to make the edits in.

The newly created named version has the following details:

New named version for work order #2754
New named version for work order #2754

 

Editing process

The editor connects to his named version, locates the nursing home on the map, and starts the editing process.

Bedford Alzheimer's Care Center feature
Bedford Alzheimer's Care Center feature

Jack changes the number of total beds to 70, marks the change in ownership in the last 12 months, and logs one facility report. When he is finished, he saves his edits.

The edits made by Jack in the named version
The edits made by Jack in the named version

Reconcile and review process

The next step, as part of his role as field editor, is to reconcile his named version with the default version. Because conflicts have been detected, he will go over them using the Conflicts view.

Reconcile process
Reconcile process

In the Conflicts view, he assesses the conflict type as Update-Delete, which means that the Nursing Home feature #5146 was updated in the current version (the editor’s named version) but deleted in the target version (the default version).

The Conflicts view
The Conflicts view

After looking at the conflict details, Jack decides this conflict will be better assessed by his supervisor. He adds a review note explaining the context of this conflict in preparation for transferring this version to his supervisor. Conflict review notes and the ability to preserve unreviewed conflicts across multiple review sessions is a feature available for branch versioning. To learn more, see Manage branch version conflicts.

Review note added
Review note added

QA/QC process

In traditional versioning, the editor would have posted the edits to the intermediate QA version for the supervisor to review and then they would post to default.

For this branch versioning workflow, the editor will transfer ownership of the version to his supervisor for review of the conflicts by changing the version properties as part of the QA/QC workflow as follows:

Change of version onwership
Change of version onwership

Note:

This is just one example of how the version properties can be used to perform QA/QC. You can adjust these and make your own combination based on your exact workflow.

 

Supervisor review (JMURPHY)

The supervisor, JMURPHY, will then connect and add the data to the map.  While in the Versions view, he can see all versions regardless of access type. This is because his portal user has elevated privileges as a version administrator for this service.

Versions view
Versions view

He uses the Filter Versions tool to filter through the list of versions and to quicky display only the ones he owns, rather than scanning through a long list of versions. This is beneficial for administration purposes, especially for large organizations or lengthy projects that involve a great number of editors, as it allows the version administrator to focus only on the versions that need his attention.

Filter Versions
Filter Versions

From the curated lists of versions, he selects the ones that have a note as ready for review and performs a bulk reconcile and post.

Versions ready to be reviewed
Versions ready to be reviewed

In a traditional versioning set up, all edits ready for QA/QC would have been stored into one version, the intermediate QA version. In branch versioning, the supervisor will most likely have multiple versions to reconcile and post, as the edits remain in the named versions. At a first glance, this might look like a big administrative load for the supervisor; however, it can be eased by the Reconcile/Post tool or Reconcile Versions geoprocessing tool. Compared to the Reconcile option on the ribbon, this tool allows a version admin to bulk reconcile and post multiple versions in the same process. Because each editor is required to reconcile their own versions and resolve conflicts that are within their area of work, the supervisor will only need to manually review the versions with persisting conflicts.

For this example, the versions with the ready to review note have been automatically added to the Reconcile/Post tool as the edit versions that will be reconciled. The supervisor checks the Abort if conflicts detected option and unchecks the Proceed if unreviewed conflicts are detected option. This ensures that versions with persisting conflicts are not processed and have to be manually reviewed by the supervisor. The options for Post versions after reconcile and Delete versions after post are also checked. These versions will have their edits automatically posted to default and then the versions will be deleted.

Having multiple versions to reconcile coupled with the Reconcile/Post tool gives a supervisor a more granular control to managing edits from field editors. For example, in a scenario where edits cannot be validated by the supervisor, he can send back the individual version to the editor by changing the ownership back to him and adding a suggestive review note. This prevents holding back edits from his colleague’s edit versions that are vetted and are good to go into the default version.

Bulk recocile and post
Bulk recocile and post

A warning message appears letting the supervisor know version work order #2745 has preexisting conflicts and was skipped. He will now have to manually review them.

Reconcile conflict warning message
Reconcile conflict warning message

After connecting to the specific version, the Conflicts view is used by the supervisor to review the conflict details. He reads the conflict review note left by the previous version owner and scans for the editor tracking field, last_edited_user, that tell him which user made the edits to this feature in both the current and the target version.

Final conflict review by the supervisor
Final conflict review by the supervisor

After discussing with both editors, Jack Groome and Colin Thomas, he reaches a resolution and confirms the edits in the current version are the correct ones. He marks the conflict as reviewed, proceeds to reconcile, and posts them to the default version.

 

Mark conflict as reviewed
Mark conflict as reviewed

He can confirm the edits are now available in the default version and the web map consumed by the Medical Services feature service.

Edits are available in the default version
Edits are available in the default version

 

In summary, we showed how you can have a separate level of QA performed before edits are posted to default by using the version ownership, description, and access type. This additional level of QA can be used to review and perform validation tasks against the data, similarly to the QA version in traditional versioned workflows.

We hope reviewing this specific QA/QC workflow helped to answer some of your questions related to options for workflows with branch versioning. We are always interested in hearing more about the details of how your organization performs QA/QC workflows.

 

Photo by Waldemar on Unsplash

About the authors

Product Engineer on the Geodatabase team - specializing in enterprise databases, versioning, and all things geodatabase. A true southerner // Chick-fil-A lover // Beach bum

Connect:

Product Engineer on the Geodatabase team, passionate about making a difference in people's lives using GIS. Hiker and a true Éclair and Crêpe lover in her free time.

Next Article

Basemap Releases Include Over 180 New and Updated Communities

Read this article