Branch version scenarios

Available with Standard or Advanced license.

Versioning can be applied in various scenarios depending on the business requirements of each organization. General considerations for editing workflows and recommended versioning configurations are described with illustrations below.

Workflows vary among organizations. 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. Once 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 an 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 via 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 your data is registered as branch versioned and the Version Management capability is not enabled on the web feature layer, all operations, such as querying and editing the data, occur on the published default version. You cannot use any of the Version Management operations such as those that create, modify, or delete versions, and you cannot use the reconcile and post operations.

Learn more about editing considerations for feature services.

General considerations

Keep the following in mind when considering branch versioning:

• After registering datasets as branch versioned, editing will be completed through the feature service. Portal users will need to have access to the web feature layers and a role that includes the privilege to edit features.
  • Geoprocessing tools that modify data can be used when directly accessing branch versioned datasets from a database connection. These tasks should be reserved for the data owner to facilitate operations such as bulk data loading.
• Named branch versions are only available in the service in which they are created.
• When setting version access permissions, consider your version workflow strategy along with the needs of the various users working within that framework.
• Version ownership is based on the active portal user. The portal user's privileges also determine the versions the user can view, edit, and manage.
• Conflict resolution for branch versioned data can be managed over multiple sessions.
• 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 versions, the compress operation is no longer 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 the default version

The default version is the published version users access when working with branch versioned data. This is the initial version most users are exposed to when consuming web feature layers via services.

To edit branch versioned data, access the web feature layers from your organization's portal. When editing layers with the Version Management capability enabled, edits are saved immediately to the underlying data source. The default version can always have multiple editors (for example, multiple admins), though setting the version access level determines who can access and edit this version. When the version access is set to public, all portal users can directly edit the default version and editors can post edits to it. Editing the default branch version is equivalent to standard database short transactions. When editing the default branch version, your first edit in the edit session 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 default version directly, 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.

When publishing branch versioned data, the publisher can enable the Version Management capability. The version management service (VMS) exposes the Version Management operations, which are necessary to support web feature layers that work with branch versioned datasets.

Version access is based on a combination of the active portal user's privileges and the access permission of 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—All portal users can edit the default version directly and editors can post edits to it.
• Protected—Only users who are the version administrator (portal users with higher privileges) can edit or post edits directly to the default version. Editors must create a named version to begin editing.

Considerations

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

• Multiple users can edit the default version simultaneously.
• When editing the default version with the Version Management capability enabled, you cannot undo and redo edits.
• There is no conflict detection applied when editing 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 has a simplified version hierarchy that allows only one level of named versions to be created from the default branch version. The version access level for the default branch version is set to public by default. To work with branch versioned datasets in a named version and have them participate in versioning workflows, enable the Version Management capability when you publish the service. Once enabled, the version management service (VMS) exposes capabilities to create, modify, and delete versions, as well as reconcile and post edits for versions, which are necessary to support web feature layers that work with branch versioned datasets. You can create a named version to provide editors their own unique, isolated view to work with the same data at the same time.

If version access to the Default version (orange) is set to public, editors can edit the Default version directly 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 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 version properties and set the version access level to protected, allowing users to continue to view the default version but restricting their access level to read-only. Any editor wanting to modify the data must create a named version.

If version access to the Default version (orange) is set to protected, editors can only make edits to 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, the default version is used. 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 either the default version or a named version if one exists. When editing 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 Pro 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 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 a named version, they must be the only user connected to that version.

Setting the version access to private when creating a named version helps avoid blocking the version for editing. A named version 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 make edits to 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.

Once all modifications to the work order, job, or project are completed, you can perform a reconcile to retrieve changes from the default version and resolve any 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 to the protected default version, integrating them into the default version. Then the named version can be deleted.

Considerations

Consider the following when working with or editing a named version:

• Branch versioning has a simplified version hierarchy allowing only one level of named versions to be created from the default version.
• Only one editor per branch version or multiple readers is allowed. Once an editor begins editing a branch version, an exclusive lock is obtained and no other user can connect to the version.
• Undo and redo capabilities are available when working in a named version.
• Reconcile and post operations are done using the default version as the target version; you cannot reconcile or post using another named version.
• Since the branch versioning model is a temporal model in which all records and edits are tracked into 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 service for each level of user. For example, you may have a group of editors and viewers who need read-only access to the system. 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.

• The first web feature layer is published as an editable web feature layer with the Version Management capability enabled and is created for the purpose of being shared with only the editors in the organization to make edits.
• A second web feature layer is published with the query capability enabled and the create, update, delete, export, and sync operations are disabled. This web feature layer, which does not have editing enabled, is published for the purpose of providing a noneditable service to be shared with viewers who you want to have a read-only view of the published data.

  Note:

  When preparing data to publish a feature service, the connected geodatabase user must be the owner of the data and the geodatabase must be registered as a data store. For branch versioning, version ownership is based on the active portal user. If you plan to use the web feature layer for editing or viewing only, your portal user must be assigned a role with the Edit or Viewer privilege.

Once the first web feature layer is published, the editors can either edit the default branch version or edit a named version and reconcile and post it using the default version in this editable web feature layer. Once edits have been completed or posted to the default version, the changes are immediately available and are available for a separate web feature layer to be published 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.

As additional edits are made to the default version in the editable web feature layer, these edits are immediately visible in the default version of the read-only web feature layer that is available to the group of users granted the default Viewer role.

Considerations

Consider the following when supporting editors and viewers:

• Editable web feature layer
  • The editable web feature layer will have the Version Management capability enabled and will be shared with just the editors in the organization. They can create, modify, and delete versions as well as make edits and perform reconcile and post operations.
• 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 service. The portal user that published the feature service will be the version administrator for this service. The version administrator can then share the web feature layer with the group or groups that contain the members who need to edit the web feature layer. Once shared, they can create, modify, and delete versions as well as make edits and perform reconcile and post operations.
• Noneditable web feature layer with only the query capability enabled
  • The noneditable web feature layer with only the Query capability enabled can only be shared with viewers who have read-only access to the data. Viewers can only access the default version of this query-only service, as the version management server is not enabled.
  • 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 Pro 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 particular 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 single named version called Proposed is created from the default version and represents the proposed stage of this process. Once edits are completed in this proposed stage, the user changes the ownership of the version and assigns it to the version administrator. The administrator user 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 single named version called Constructed is created from the default version and represents the construction stage of this process. Once edits are completed in this constructed stage, the user changes the ownership of the version and assigns it to the administrator user. The administrator user reviews and completes the QA/QC process and reconciles and posts the changes to the protected default version. Once posted, 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 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 administrator user who then completes the QA/QC process and reconciles and posts using the default repeats until you reach the completed or final stage.

Considerations

Consider the following when working with project stages:

• This QA/QC workflow process can include the following:
  • Attribute rules—Attribute rules improve the editing experience and data integrity for geodatabase datasets. They are user-defined rules that can be used to automatically populate attributes, restrict invalid edits during edit operations, and 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.
  • Workflow Manager—Workflow Manager allows you to streamline and standardize your business processes, which can be represented as a workflow using a series of steps connected by paths in 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. 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 Pro using the Download Map button.

When working with branch versioned data and mobile editors, learn how to use and work with branch versioned data in feature services that you take offline.

Distributed collaboration also supports web feature layers including those running on branch versioned data. It allows sync-enabled web feature layers to be shared as a copy when the web feature layers shared across the collaboration are running on separate copies of the data. To learn more about the collaboration process and collaboration concepts, see How collaboration works.