Branch version scenarios

Available with Standard or Advanced license.

The business requirements of your organization will dictate which branch versioning scenarios you use.

Workflows vary, but they often progress in discrete stages, with each stage requiring the allocation of a different set of resources and business rules. Typically, each stage in the overall process represents a single unit of work, such as a work order or job. To manage these, you can create a separate, isolated version and modify it. When this work is complete, you can integrate the changes into the default version.

Understanding the organizational and business requirements along with the key points regarding branch version scenarios will help you determine what's best for your organization.

The concept of versioning is the same whether you use branch versioning or traditional versioning. Versioning provides multiple representations of the data without copying data, allows concurrent editing, and allows users to have versions for extended periods of time. See Overview of versioning for more details.

Branch versioning is a type of geodatabase versioning that works with the ArcGIS Enterprise Web GIS model using a services-based architecture to allow multiuser editing workflows and long transaction scenarios through web feature layers. Web feature layers (also known as feature services) are layers that are shared to support displaying, querying, and editing data on the web.

A general overview of the branch versioning workflow is shown.

Branch versioning supports simple feature classes and tables along with more complex geodatabase datasets such as utility networks and parcel fabrics in an enterprise geodatabase. It is important to prepare the dataset properly to accommodate a variety of workflows that can be completed by accessing the web feature layers. The data must be registered as branch versioned and published from an enterprise geodatabase. Once the web feature layers are published, branch versioning allows you to track edits for insert, update, and delete operations on features in a version.

See the editing workflow options for a complete list of datasets supported with branch versioning.

If the data is registered as branch versioned and you do not enable the Version Management capability on the web feature layer, all operations—such as querying and editing the data—occur on the default version. You cannot use any of the Version Management operations such as those that create or delete named versions or modify versions, and you cannot use the reconcile and post operations.

Learn more about editing considerations for feature services.

The following sections provide general considerations for branch versioning plus descriptions of several branch editing scenarios and recommended versioning configurations.

General considerations

Keep the following in mind when considering branch versioning:

• Editors must edit branch versioned data through the web feature layer; they cannot connect to the geodatabase in ArcGIS AllSource using a database connection and edit the data. This means that you must publish branch versioned data as a web feature layer and share the web feature layer with the appropriate audience—a group, the organization, or the public. If you share the web feature layer with a group or the organization, portal members who need to edit the feature layer must be members of a role that includes the privilege to edit features.

  Note:

  The owner of the branch versioned data can connect to the geodatabase in ArcGIS AllSource using a database connection and run geoprocessing tools that modify the branch versioned data. This should be reserved for operations that facilitate bulk data loading, such as Append or Copy Features.

• When editing branch versioned data, the attribute table may not immediately reflect the updates. To view the updated data in the attribute table, you must refresh the data source. You can do this by either clicking the Refresh button on the Versioning tab of the ribbon or in the Contents pane, choose List By Data Source and right-click the appropriate data source for the branch versioned data and choose Refresh.
• You must connect to the web feature layer to create named versions. The owner of the named version is the portal member used to authenticate the connection to the active portal when you create the named version.
• When setting version access permissions, consider your version workflow strategy along with the needs of the various users working within that framework.
• The privileges of the portal member who accesses the web feature layer, along with version access permissions and settings on the web feature layer, determine what the portal member can do with branch versions and the data they contain.
• Conflict resolution for branch versioned data can be managed over multiple edit sessions. You can even close the ArcGIS AllSource project and reopen and continue managing conflicts.
• Branch version administration workflows are streamlined due to a simplified data model. While reconcile and post operations are still performed to merge edits and post changes to the default version, the compress operation is not needed for branch versioned datasets. Edits are tracked using archiving, which allows all edits to be stored in the base table of the dataset.

Edit data in the default version

To allow others to edit data in the default version, publish the branch versioned data. The web feature layer automatically references the default version of the data.

When editing data in the default version, edits are saved immediately to the underlying data source. Editing data in the default branch version is equivalent to standard database short transactions. When editing data in the default branch version, your first edit begins the transaction, and the individual edit operations you perform are each automatically committed to the database as a single transaction without needing to save the edits. The changes you make are available to all other users and applications accessing the web feature layer from the default version when your transaction is complete.

If version access to the default version (orange) is set to public, editors can edit the data in the default version, which is the published version. Viewers who access this published web feature layer (feature service) with version management enabled also see the updates made to the default version.

Version access is based on a combination of the active portal user's privileges and the access permission configured for the version. The portal user privileges and the version access permission level (public or protected) of the default version determine the types of editing workflows permitted.

• Public—If the access level of the default version is set to public, all portal users can edit the data in the default version, and users who edit data in named versions can post their edits to the default version. This is the default access setting for the default version.
• Protected—If the access level of the default version is set to protected, only users who are the version administrator (portal users with higher privileges) can edit data in the default version or post data edits from named versions to the default version. All other editors must create a named version to begin editing.

Considerations

Consider the following when working with or editing data in the default version:

• Multiple users can edit data in the default version simultaneously.
• When the Version Management capability is enabled on the web feature layer, you cannot undo and redo edits you make to data in the default version.
• There is no conflict detection applied when editing the data in the default version. When one user updates a feature and saves the edits, and another user updates the same feature and saves the edits, the last update made overwrites the first.

Edit a named version

If you manage multiple projects, work orders, or jobs, you need a structured approach to workflow management. Discrete work units involving many edit sessions and spanning numerous days, weeks, or months can be maintained without affecting the default version. Examples of these discrete work units are a highway improvement scheme, the installation of a new phone service, or an ongoing maintenance project for a gas pipeline. When a work order or project is initiated, to isolate edits, you can create a named version from the default version.

Branch versioning allows only one level of named versions to be created from the default branch version. To work with branch versioned datasets in a named version and have them participate in versioning workflows, do the following:

• Enable the Version Management capability when you publish the branch versioned data. Once enabled, the version management service (VMS) exposes capabilities to create, modify, and delete named versions, as well as reconcile and post edits from named versions to the default version. This is necessary to support web feature layers that work with branch versioned datasets.
• Create a named version to provide editors their own unique, isolated view to work with the same data at the same time, and allow you to identify and resolve conflicts before posting edits to the default version.

If version access to the default version (orange) is set to public, editors can edit the data in the default version, or they can create and edit a named version, such as Version A (green) or Version B (purple). Then editors can reconcile (R) and post (P) their edits from the named version to the published default version. Viewers who access this published web feature layer (feature service) with version management enabled see the updates made or posted to the default version.

If you choose a strategy in which no one edits the default version directly, the geodatabase administrator can modify the default version properties and set the version access level to protected, allowing users to continue to view the data in the default version but restricting their access level to read-only. Any editor wanting to modify the data must create a named version and edit the data in it.

If version access to the default version (orange) is set to protected, editors can only edit data in a named version, such as Version A (green) or Version B (purple). Editors can reconcile (R) their edits and version administrators can post (P) the edits to the protected default version. Viewers who access this published web feature layer (feature service) with version management enabled see the updates posted to the default version.

When a web feature layer with the Version Management capability enabled is initially added to the map from a portal connection, it accesses the default version. However, you can use the Change Version dialog box to switch between versions. When you edit a web feature layer with Version Management enabled, you can edit the data in either the default version or a named version if one exists. When editing data in a named version, you can undo and redo individual edits as well as save or discard groups of edits. To access these editing capabilities in a named version, the version being edited must be isolated from other editors and viewers. To accomplish this, ArcGIS AllSource provides locking mechanisms to limit access to versions for viewing or editing.

The locking model allows for multiple simultaneous viewers or a single editor as follows:

• Once an editor begins editing data in a named version, an exclusive lock is obtained and no other users can connect to the version during the edit session.
• At the time an editor starts editing data in a named version, they must be the only user connected to that version.

To avoid some of this locking, set the access permission on the named version to private. A named version with the access permission set to private prevents other users, with the exception of users with elevated privileges (for example, the portal administrator and the version administrator), from connecting to this version.

If version access to the default version (orange) is set to protected, editors can only edit data in a named version, such as Version A (green) or Version B (purple). To prevent other users from connecting to their named version, editors can set the version access to their named version to private. Editors can reconcile (R) their edits and version administrators can post (P) the edits to the protected default version. Viewers who access this published web feature layer (feature service) with version management enabled see the updates posted to the default version.

When all modifications to the work order, job, or project are completed, you can perform a reconcile operation to retrieve changes from the default version and resolve the conflicts that are discovered. Branch versioning allows you to manage conflicts for multiple edit sessions, review and resolve them, and leave and come back later to continue. You can review conflicts one at a time and, if necessary, make changes. Once completed, the version administrator can post the modifications from the named branch version to the protected default version, integrating the edits into the default version. Then the named version can be deleted.

Considerations

Consider the following when editing the data in a named version:

• Branch versioning allows only one level of named versions to be created from the default version. In other words, you cannot create a named version from a named version.
• Only one editor per named branch version is allowed, or multiple users can read from the named version. Once an editor begins editing data in a named version, an exclusive lock is obtained and no other user can connect to the version.
• You can undo and redo edits when editing the data in a named version.
• Reconcile and post operations are done using the default version as the target version; you cannot reconcile with or post to another named version.
• Because the branch versioning model is a temporal model in which all records and edits are tracked in the same base table, there is no requirement to compress.

Support editors and viewers

If your organization needs to support multiple tiers of users, each requiring different operations, the recommended approach is to create one web feature layer for each level of user. For example, you may have editors and viewers who need access to the versioned data. In this scenario, you can support these editors and viewers by publishing two web feature layers (feature services) from the same underlying feature class registered as branch versioned.

Once editors post edits to the Default version (orange) in the editable web feature layer (feature service), these edits are reflected in the underlying feature class registered as branch versioned. They are visible to viewers who are accessing the noneditable web feature layer (green), as this web feature layer is also published from the same underlying feature class.

• Publish the first web feature layer is as an editable web feature layer with the Version Management capability enabled. Share this web feature layer with a group whose members are allowed to edit the data.

  After the first web feature layer is published, the editors can either edit the data in the default branch version or edit the data in a named version and reconcile and post their edits. When edits have been completed and, if necessary, posted to the default version, the changes are immediately available in the default version. These edits will be available for the web feature layer you publish for read-only users below.

• Publish a second web feature layer with the query capability enabled and the create, update, delete, export, and sync operations disabled. When publishing this web feature layer, which does not have editing enabled, you can leave the Version Management capability disabled. Share this web feature layer, which does not have editing enabled, with a group whose members only require a read-only view of the data in the default version or share with your organization to allow all organization members a read-only view of the data in the default version.

Considerations

Consider the following when supporting editors and viewers:

• Because the editable web feature layer will have the Version Management capability enabled and will be shared with the editors in the organization, the editors can create named versions, delete named versions, and modify properties of the named versions as well as edit data and perform reconcile operations. If the default version access permission is set to public, the editors can post edits from the named versions to the default version.
• To work with branch versioned datasets in a named version and have them participate in versioning workflows, you must enable the Version Management capability when you publish the web feature layer. The portal user that published the web feature layer will be a version administrator for this layer. The owner of the web feature layer can share the web feature layer with the group or groups that contain the members who need to edit the web feature layer. Once shared, editors can create, modify, and delete versions as well as make edits and perform reconcile and post operations.
• Because only the Query capability is enabled on the second web feature layer and version management is not enabled, the members with whom you share the second web feature layer can only access the default version.
• The Query operation is required for viewers to view the data in the web feature layer. For this reason, the Query operation is enabled when publishing from ArcGIS AllSource and cannot be disabled.

Project stages

Work order management systems and the process of a work order assignment go through multiple stages in an organization. Many projects evolve through a prescribed or regulated group of stages that require engineering, administrative, or legal approval before proceeding to the next stage. These stages can include the initial proposed design, construction, survey in the field, construction as-built, and project complete. During each stage of a project, updates can occur multiple times over subsets of the data. This process is essentially cyclical: a work order is initially assigned to an engineer and modified over time as the project evolves through the various stages before full integration with the production database. It may be a requirement in the last step of each stage to have an administrator take ownership to perform quality assurance (QA) and quality control (QC) or a validation step prior to posting.

In the following scenario, a named version called Proposed is created from the default version and represents the proposed stage of this process. When edits are completed in this proposed stage, the user changes the ownership of the version to the version administrator. The version administrator reviews and completes the QA/QC validation process and reconciles and posts the changes to the protected default version. Once posted, the Proposed version can be deleted.

An editor can create a named version called Proposed (green) and reconcile (R) from the protected Default version to the Proposed named version. While the editor (green) edits in the Proposed named version, the viewers see what's published from the Default version (orange). Once the editor completes their edits and changes the version ownership to the admin user (blue) to complete the QA/QC process, the admin user reconciles (R) and posts (P) the updates using the Default version. Once the updates are posted to the Default version, the viewers see the new updates when accessing this published web feature layer.

Next, a named version called Constructed is created from the default version and represents the construction stage of this process. When edits are completed in this constructed stage, the owner of the named version changes ownership of the version to the version administrator user. The version administrator reviews and completes the QA/QC process and reconciles and posts the changes to the protected default version. Once edits are posted to the default version, the Constructed version can be deleted.

An editor can create a named version called Constructed (purple) and reconcile (R) from the protected Default version to their Constructed named version. While the editor (purple) makes edits to the Constructed named version, the viewers see what's published from the Default version (orange). Once the editor completes their edits and changes the version ownership to the admin user (blue) to complete the QA/QC process, the version administrator (admin) user reconciles (R) and posts (P) the updates using the Default version. Once the updates are posted to the Default version, the viewers see the new updates when accessing this published web feature layer.

This life cycle process of generating named versions, making edits, changing the ownership of the version to the version administrator who then completes the QA/QC process and reconciles and posts to the default version repeats until you reach the completed or final stage.

Considerations

You can use the following with all of the scenarios described above, but they are especially helpful in this QA/QC workflow.

• Attribute rules—Attribute rules improve the editing experience and data integrity for geodatabase datasets. They are user-defined rules that can automatically populate attributes, restrict invalid edits during edit operations, or perform QA checks on existing features.
• ArcGIS Data Reviewer—Data Reviewer allows you to manage data for data production and analysis by providing a system for automating and simplifying data quality control that can improve data integrity. Data Reviewer includes a set of QC tools that provide an efficient and consistent data review process such as analyzing the attribute values of tables and the spatial relationships between features.
• ArcGIS Workflow Manager—ArcGIS Workflow Manager allows you to streamline and standardize business processes, which can be represented as a workflow using a series of steps connected by paths in ArcGIS Workflow Manager. Workflows organize and clarify tasks to ensure that no step is missed. Information is automatically recorded for each activity and tools are provided to report information about each task. ArcGIS Workflow Manager includes tools for allocating resources and tracking the status and progress of jobs. Various email notifications are provided to notify users of the tasks assigned to them, tasks completed, and spatial data edited, among other activities.

Distributed data management

You can support mobile editor workflows using mobile data collection apps or in ArcGIS AllSource using the Download Map button.

See Work with offline maps and branch versioned data to learn how to implement branch version scenarios for mobile editors.

Web feature layers that access branch versioned data are also supported in distributed collaboration workflows. Collaboration allows you to share sync-enabled web feature layers as copies to access different versions of the data. To learn more about the collaboration process and collaboration concepts, see How collaboration works.