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
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.
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:
- Number of certified beds increased to 70
- Recent change in building ownership reported
- One facility incident report to be logged in
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:
- Version name is the work order number.
- Version owner is the portal user assigned to the field worker employee.
- Parent version is the protected default version.
- Version description explains who owns the version and what it is used for.
- Version access type is set to private, which means only the version owner or version administrator can view or connect to this version.
Editing process
The editor connects to his named version, locates the nursing home on the map, and starts the editing process.
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.
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.
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).
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.
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 the version owner to his supervisor, jmurphy.
- Add a Ready to review note in the version description. This will be the supervisor’s cue to reconcile the version.
- Change the version access type to protected. This will ensure he still has access to the version after he is no longer the version owner in case he needs to have a conversation with his supervisor about the edits in conflict.
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.
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.
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.
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.
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.
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.
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.
He can confirm the edits are now available in the default version and the web map consumed by the Medical Services feature service.
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.
Commenting is not enabled for this article.