Work with offline maps and branch versioned data

When you use branch versioned data in feature services that you take offline, you can work with the default version of the data or create a version for each downloaded map.

Be sure you prepare your data for offline use before you proceed with publishing and creating offline web maps.

Work with the default version

If you don't need to edit offline data or review edits made while offline, you can publish sync-enabled feature services that allow you to synchronize directly with the default version of the branch versioned data.

You must do the following when publishing a feature service (web feature layer) to use this workflow:

• When publishing to a federated server, you must publish a feature layer that references a registered data source.
• If data needs to be edited when offline, you must enable the editing operations required by your editors. You can also use this workflow if you only need to take branch versioned data offline for reference, in which case you do not need to enable editing options on the feature layer you publish.
• Configure the feature service for sync when you publish.
• Choose the None option under Sync > Version Creation when you publish. None is the default setting, as this maintains backward compatibility with 10.8 and earlier releases.
• Enable the Version Management capability on the feature layer when you publish. You cannot enable this capability after publishing.
• Change the Instance Type setting for the GIS Server site to Dedicated instance; you cannot publish feature services with the Version Management capability enabled to a site that uses shared instances.

Once the feature service is published, create a web map that is enabled for offline use and add the feature service to it. Share the web map with a group that contains the portal members who need to take the data offline.

Create a version for each downloaded map

A new geodatabase version (referred to as a replica version) is created each time you download and take a map offline that contains an editable feature service that is published with the Create a version for each downloaded map option enabled. When the replica version is created, it references the current state of the default version. The replica version name includes the following to ensure the version name is unique:

• The name of the portal account that downloads the map
• The name of the feature service
• A unique identifier (ID)

In this workflow, when a client synchronizes edits with the feature service, edits are applied to the replica version. As a result, you need to perform additional reconcile and post processes to get the edits into the default version and share them with others.

You must do the following when publishing a feature service to participate in this workflow:

• When publishing to a federated server, you must publish a feature layer that references a registered data source.
• This workflow assumes edits will be made while offline; therefore, you must also enable the editing operations required by these editors. If the map contains a read-only feature service (only query and sync are enabled on the feature service), and the feature service contains branch versioned data, no version is created when the map is downloaded. In that case, you are taking data directly from the default version.

  Note:

  Even if the feature service is read-only (only query and sync are enabled), the database user connecting to the geodatabase when publishing must have privileges to edit the data.

• Configure the feature layer for sync when you publish.
• Choose the Create a version for each downloaded map option under Sync > Version Creation when you publish. With this option, a version is generated from the current state of the default version each time you take a map offline that contains an editable feature service.
• Enable the Version Management capability on the feature layer when you publish. You cannot enable this capability after publishing.
• Change the Instance Type setting for the GIS Server site to Dedicated instance; you cannot publish feature services with the Version Management capability enabled to a site that uses shared instances.
• Do not share the feature layer with everyone. Editors must sign in to the portal to take the web map and feature layers offline; therefore, there is no reason to share this layer with the public.

Once the feature service is published, create a web map that is enabled for offline use and add the feature service to it. Share the web map with a group that contains the portal members who need to take the data offline for editing and synchronization.

Examples of each workflow

The next two sections describe scenarios that use each workflow. In both examples, fieldworkers use ArcGIS Collector, but you can also use ArcGIS Pro or a custom app created using ArcGIS Runtime.

The following table compares the two workflows to help you decide when to use each one:

	Workflow 1: Synchronize with the default version	Workflow 2: Synchronize with a replica version
Version from which the feature service is published	Default version	Default version
Is a version created?	No	Yes, for each downloaded map
Number of versions created	None	Many
The version with which offline edits are synchronized	Default version	Replica version
Latency between offline edits and updates to default version	Low	High
Maps involved in quality assurance	Not applicable	All maps

Workflow 1: Synchronize with the default version

In this workflow, fieldworkers take a web map offline in ArcGIS Collector, edit in the field, and synchronize when they return to the office. When fieldworkers synchronize their changes, the feature service applies the edits directly to the default version in the enterprise geodatabase.

This workflow is most useful if you don't need to review edits or execute attribute rules on the data before making it available to other people. Because you cannot review and resolve conflicts for changes made by different editors, the last edit applied to the default version is always the one that is saved to the default version.

The following steps summarize the workflow. Several people with different roles and privileges are involved in this workflow.

1. The owner of the data in the enterprise geodatabase must prepare the branch versioned data for synchronization with the default version.
2. Another member of the organization who has editing privileges on the data in the geodatabase and has privileges to publish ArcGIS Server web services creates a map in ArcGIS Pro. This person adds the branch versioned data to the map and sets symbology, an editing template, and other desired configurations to the map. This person registers the database connection used to access the data with an ArcGIS GIS Server site that is federated with the active portal in the ArcGIS Pro project. Next, he or she publishes the map to the federated ArcGIS Server site. The publisher must set all of the following options in the Share As Web Layer pane:
   1. Choose Reference registered data in the Data section on the General tab.
   2. Check Feature in the Layer Type section on the General tab.

      

   3. Click the Configuration tab and click the Configure Web Layer Properties button next to Feature.

      

   4. Under Operations, choose the editing operations required by the fieldworkers who will take the data offline. Also check the Enable Sync check box.

      

   5. Scroll down to the Sync section. Under Version Creation, choose None.

      

   6. When you finish setting layer options, click the back arrow (<) to close the Layer Properties dialog box.
   7. On the Configuration tab, under Capabilities, check the Version Management check box.

      

   8. On the Configuration tab, click the Configure Pooling button at the top. For Instance Type, choose Dedicated instance.

      

3. The publisher sets other options if necessary, analyzes the settings to ensure there are no errors, and publishes the feature layer.
4. The publisher or any other member of the portal who has privileges to create content and has access to the feature layer item creates a web map to be taken offline that contains the feature layer published in the previous step. This person shares the web map with a group whose members perform offline edits.
5. Each member of the group starts ArcGIS Collector, signs in to the portal, and downloads the web map.

   Once downloaded, Collector switches the map to reference local data. At this point, the map can be edited without having to be on the network. A sync button appears on the map in Collector to indicate that it is referencing the local data.

6. The fieldworkers edit the data on their local devices while in the field. When each fieldworker returns to the office, he or she synchronizes that day's edits.

   Edits from each worker are applied directly to the default version in the geodatabase. This means that everyone with access to the data in the geodatabase can immediately see the edits made by the fieldworker. It also means that if more than one fieldworker edits the same feature, the edit made by the last worker to synchronize overwrites earlier changes made by anyone else who synchronized edits.

7. After synchronization completes, each fieldworker deletes the offline map from his or her device.

Workflow 2: Synchronize with a replica version

In this workflow, the following takes place:

• A replica version is created every time a fieldworker downloads a web map to ArcGIS Collector for offline editing.
• When fieldworkers finish editing and synchronize their changes, their edits update the replica version. Also when they synchronize, they download changes from the default version.
• Once edits are in each replica version, a member of the default portal administrator role or a member of a custom role with privileges to manage all versions and edit features (hereafter referred to as a version administrator) reviews edits and corrects problems and conflicts before pushing the edits from each replica version to the default version.
• Because fieldworkers always download data from the default version when they synchronize, they only receive edits that have been reviewed and approved by an administrator.
• When fieldworkers are done with all their edits and synchronize them for the final time, they delete their offline maps.
• After the portal administrator or version administrator finishes reviewing the data and reconciles and posts all edits for the final time, he or she deletes the replica versions.

This workflow is useful if you need to review edits—manually or via scripts that execute attribute rules on the data—before making it available to other people. You can also review any conflicts that arise when mobile editors and editors in the office edit the same data.

The following steps summarize this workflow. Several people with different roles and privileges are involved in this workflow.

1. The owner of the data in the enterprise geodatabase must prepare the branch versioned data for synchronization with a replica version.
2. Another member of the organization who has editing privileges on the data in the geodatabase and has privileges to publish ArcGIS Server web services creates a map in ArcGIS Pro. This person adds the branch versioned data to the map and sets symbology, an editing template, and other desired configurations to the map. This person registers the database connection used to access the data with an ArcGIS GIS Server site that is federated with the active portal in the ArcGIS Pro project. Next, he or she publishes the map to the federated ArcGIS Server site. The publisher must set all of the following options in the Share As Web Layer pane:
   1. Choose Reference registered data in the Data section on the General tab.
   2. Check Feature in the Layer Type section on the General tab.

      

   3. Click the Configuration tab and click the Configure Web Layer Properties button next to Feature.

      

   4. Under Operations, choose the editing operations required by the fieldworkers who will take the data offline. Also check theEnable Sync check box.

      

   5. Scroll down to the Sync section. Under Version Creation, choose Create a version for each downloaded map.

      

   6. When you finish setting layer options, click the back arrow (<) to close the Layer Properties dialog box.
   7. On the Configuration tab, under Capabilities, check the Version Management check box.

      

   8. On the Configuration tab, click the Configure Pooling button at the top. For Instance Type, choose Dedicated instance.

      

3. The publisher sets other options as necessary, analyzes the settings to ensure there are no errors, and publishes the feature layer.
4. The publisher or any other portal member with privileges to create content and has access to the feature layer item creates a web map to be taken offline that contains the feature layer published in the previous step. This person shares the web map with a group whose members perform offline edits.
5. Each member of the group starts ArcGIS Collector, signs in to the portal, and and downloads the web map.

   A replica version is created in the enterprise geodatabase for every downloaded map. The replica version is automatically assigned a name in the following format to ensure the name is unique: <name of the portal user who downloaded the map> _<feature service name>_<ID>.

   Once downloaded, Collector switches the map to reference local data. At this point, the map can be edited without having to be on the network. The Sync button appears on the map in Collector to indicate that it is referencing the local data.

6. Fieldworkers edit the offline data throughout the day. When they have network connectivity, they synchronize their edits to their replica version.
7. At midday each day and every morning, the portal administrator or a version administrator does the following:
   1. Reviews the field edits in each replica version. Because the feature classes in the enterprise geodatabase have attribute rules defined that enforce data quality checks, the administrator evaluates these rules per version.

      Administrators can use a script to evaluate the rules or run them manually. See Automate reconcile and post operations for sync-enabled branch versioned data in the ArcGIS Pro help for a sample script.

   2. If no errors or rule violations are found, the administrator proceeds with reconciling with the default version. The administrator reviews and resolves any conflicts that are detected by the reconcile operation and posts the changes to the default version. Now that the replica version edits are present in the default version, other fieldworkers who synchronize will receive these edits.
   3. If errors or rule violations are detected, the portal administrator or version administrator has two options:

      • Fix the errors and rule violations and execute the attribute rules again to confirm data quality. Be aware that edits applied to fix errors and rule violations in the replica version are not available for download by anyone, not even mobile editors, until the replica version is reconciled with and posted to the default version. Once all errors are fixed, the administrator can proceed with reconciling, reviewing conflicts, and posting to the default version.
      • If fieldworkers need to see the updates made to the default version before the administrator finishes all the quality assurance corrections, the administrator can reconcile with the default version to pull those changes into the replica version. If there are conflicts when the administrator reconciles, the default behavior in the geodatabase is to preserve the edits in the replica version. Unapproved edits are not posted at this point, but fieldworkers will receive the changes from default version when they synchronize. The administrator can then fix errors and rule violations, reconcile, and post to the default version without blocking mobile editors from obtaining edits that were made to the default version since they last synchronized.

8. When fieldworkers are entirely finished with and have synchronized all the edits they need to make in the offline map, they can delete the maps from their devices.

   Deleting the offline map from the mobile device does not delete the replica version from the enterprise geodatabase.

9. Once a fieldworker has deleted his or her offline map and the administrator has reviewed edits and reconciled and posted data from the corresponding replica version, the administrator can delete the replica version.

   Use the replica version naming pattern to identify replica versions in the Versions view in ArcGIS Pro.

   Note:

   You cannot delete a replica version if it still references an offline map. The offline map must be deleted before you can delete the replica version.