Prepare data for offline use

To work with a map even when you're offline, you can enable a sync capability on the feature services you use in your map. The sync capability has operations that allow clients to work with a local copy of the data. If the publisher chooses to allow it, clients can edit the local copy of the data and synchronize with the feature service when connectivity is available.

Note:

In future, ArcGIS clients and developer SDKs may support the sync capability in feature services. Currently, ArcGIS Collector and ArcGIS Runtime SDK support working with maps while offline and use the sync capability to synchronize changes.

Other clients can access the sync capability through the ArcGIS REST API.

Data preparation

To use the sync capability, all the data in the feature service must be from an enterprise geodatabase and the data must be registered with the geodatabase. Also, you must prepare the data so it can be used offline and, if required, synchronized through the feature service when you have connectivity.

The data you use in a sync-enabled feature service can be either nonversioned with archiving enabled or, if your organization's data or workflows require it, the data can be registered as versioned.

Be aware that you can only enable the sync capability when all the data in the map is configured exactly the same; you cannot have a combination of versioned and nonversioned data or traditional and branch versioned data.

Privileges in the database

When you use the sync capability on an ArcGIS Server feature service, the synchronization process creates a temporary table in the enterprise geodatabase to move the data between the app and the database. That means the database user who connects to perform the synchronization must be able to create temporary tables in the database. In some database management systems, creating a temporary table requires specific privileges or other configuration. Consult your database management system documentation to verify what privileges and space requirements are needed to use temporary tables in your database, and check with your database administrator to be sure you have those privileges or access to the required tablespaces.

Nonversioned data with archiving

You can use archive-enabled, nonversioned data in a feature service that is enabled for sync functionality. When the data is nonversioned, clients always work with the current representation of the data. Back-office processes are not required for clients running offline to obtain the latest changes once they again have connectivity to the feature service.

Prepare nonversioned data as follows to participate in sync functionality:

• Enable archiving on the datasets.
• Include Global IDs on the datasets.
• Relationship classes and attachments must use a Global ID primary key. For more information, see the Attachments and relationship classes section of this topic.

For a detailed walk-through of this scenario, see Tutorial: Configure feature service data for offline use.

You can publish feature services that reference nonversioned data from a 10.2 or later release enterprise geodatabase, take the data offline for editing, and synchronize changes with the enterprise geodatabase through the feature service.

Traditional versioned data

If your organization requires any of the following, use traditional versioned data:

• The data participates in geodatabase functionality that requires it to be versioned to allow editing. For example, if the feature class participates in a geometric network, the feature dataset must be registered as a traditional version.
• Your organization has workflows in place that require the data to use traditional versioning, such as having a quality assurance version of the data.

Prepare data as follows if you need to use traditional versioning:

• Include Global IDs on the datasets.
• Register the datasets as versioned. Do not register with the option to move edits to base.
• Relationship classes and attachments must use either a Global ID column or user-managed field as the primary key. For more information, see the Attachments and relationship classes section of this topic.

You can publish feature services that reference traditional versioned data, take the data offline for editing, and synchronize changes with the enterprise geodatabase through the feature service.

See Offline maps and versioned data for more information.

Branch versioned data

You can publish feature services that reference data that is registered for branch versioning in a 10.6 or later release enterprise geodatabase. You can take data offline for editing and synchronize the changes with the enterprise geodatabase through the feature service.

Note:

When publishing data, make sure the data was added to the map using a branch version connection to your enterprise geodatabase and that all data in the map is branch versioned.

By default, offline data is created using a simple model. For example, when working with a utility network or parcel fabric, only the related feature classes are included in the offline geodatabase. The utility network dataset and the parcel fabric are not included in the offline data.

When you edit and sync your utility network data, dirty areas are created on the service. You need to validate these areas from ArcGIS Pro.

You can publish data from the default branch version from ArcGIS Pro 2.1 or later to ArcGIS Enterprise 10.7 or later. Beginning with 10.8.1 and ArcGIS Pro 2.6, you have an additional option for publishing branch versioned data that creates a named branch version from the default version when you take the feature service offline. You control which version is used in offline editing based on the following Sync > Version Creation options when you publish branch versioned data for use in an offline map:

• None—No named version is created when you take the data offline. When mobile editors synchronize with the geodatabase, they synchronize directly with the default version. This is the same behavior that has existed since ArcGIS Pro 2.1 and ArcGIS Enterprise 10.7.
• Create a version for each downloaded map—Each time you take offline the web map that contains this feature service, a named version is created. This version is also called a replica version. When mobile editors synchronize, they synchronize with the replica version.

See Offline maps and branch versioned data for information on using these options.

Synchronize with default

In this workflow, the feature service data that mobile editors take offline when they download the web map comes from the current state of the default version in the geodatabase. When someone synchronizes data they edited offline, the edits go into the default version. This means these edits are immediately available to anyone who views the data in the default version. It also means that other field editors who download data from the geodatabase will receive these updates.

This workflow requires that the data be registered for branch versioning. If the data needs to be edited, grant the privileges required on the data in the geodatabase to the user who connects to and publishes the data.

This workflow is simpler and has less lag time before edits are available, but you cannot review the edits before others can see them. If you need to review offline edits before making them available to others who access the data, you need to use a replica version.

Synchronize with a replica version

In this workflow, the publisher configures the feature service to Create a version for each downloaded map when he or she publishes the feature service to a federated GIS Server site. A named version is then created from the current state of default whenever a mobile editor takes data offline. In offline workflows, this named version is referred to as a replica version. When mobile editors synchronize field edits, the edits are applied to the replica version. Mobile workers can repeatedly sync edits to the replica version.

You must do the following to prepare the data to synchronize to a replica version:

• The data you publish must be registered for branch versioning.
• Replica tracking must be enabled on the data. Run the Enable Replica Tracking geoprocessing tool on the branch versioned layer or layers before adding them to the map and publishing. If you do not enable replica tracking on the data before publishing with the option to Create a version for each downloaded map, you'll receive an analyzer error and cannot publish until you correct the error.
• Grant editing privileges on the data in the geodatabase to the user who connects to and publishes the data.

To improve data quality, you can also create attribute rules and add or import them to your branch versioned feature classes before publishing a sync-enabled feature service.

This workflow requires a member of the default portal administrator role or a member of a custom role that has version management privileges to review and resolve conflicts and reconcile and post changes from the replica version to the default version before anyone can access the edits. That means there is more management required for this workflow and there is a greater lag time between when edits are made and when they are available to the rest of the organization. However, this workflow allows you to complete quality assurance reviews of the edits before they are generally available.

Global IDs

The Global IDs you add to the datasets you take offline cannot be based on a custom field; they must explicitly use the Global ID field created by ArcGIS. To add Global IDs to your data, use the Add Global IDs geoprocessing tool or the Add Global ID command found on the feature class, feature dataset, and table context menus in the Catalog tree.

Attachments and relationship classes

If the data you want to use offline contains attachments or participates in a relationship class, the relationship between the tables or the table and the attachment must use either a Global ID column or user-managed field as the primary key. If the ObjectID column is the primary key, an error is returned when you download data for offline use. You can use the Migrate Relationship Class geoprocessing tool to convert ObjectID-based relationship classes and attachments to use Global ID fields as the primary key.

The GIS Server site's managed database

If you enable the sync capability at the time that you publish to the GIS Server site and you choose to copy the data to the site's managed database, no data preparation is required. The publishing process will set up the data to support the sync capability automatically. If data is not copied to the site's managed database when you publish or you enable the sync capability after publishing and copying data to the managed database, you must prepare your geodatabase data as described in the previous sections.

Editor tracking

You can use editor tracking with data that is edited while offline. When you download data to the client for offline use, the existing values in the editor tracking fields are copied to the client along with the rest of the data. When working with the data offline, the date and time that features are created or edited are recorded in the create and edit date fields, respectively. These values are preserved when the data is synchronized with the service.

Note:

If your date fields store values in a time zone other than UTC, specify that time zone when you publish the service. If you do not, UTC is assumed. ArcGIS will apply the time zone you specify to all editor tracking date fields.

Offline data includes the name of the user who took the map offline. This is used with editor tracking as follows:

• For features that were created while offline, the creator name value is set to the user who took the map offline.
• For existing features that were edited while offline, the editor name value is set to the user who took the map offline. The creator name value for these features is not changed.

Either the person who took the map offline or an ArcGIS Server administrator can connect to the service and synchronize data.

Editor tracking in distributed collaboration

When using editor tracking in distributed collaboration workflows, the behaviors are as follows:

Editor tracking is enabled on feature layers for receiving organizations when it is enabled from the sending organization prior to collaboration. When the data is first copied to the receiving organizations, the editor tracking values are reset where dates are set to the current timestamp in UTC and creators and editors are set as the publishing user. The reset values reflect newly copied data into a new organization. When syncing, the editor tracking dates from the sending organization are preserved. Therefore, from the time the data is shared on forward, the receiving organization will contain the dates in which the edits were made in the sending organization. Creator and editor values for inserts and updates synced into the receiving organization will be set to the replica owner (publishing user) from when the feature layer was copied.

It is possible for editor tracking to be enabled on some layers but not others within feature layers in a collaboration. In this case, when sending from ArcGIS Enterprise or ArcGIS Online, all layers will have editor tracking enabled in the hosted feature layer in ArcGIS Online. Where layers in ArcGIS Online and ArcGIS Enterprise have editor tracking enabled, the behavior is as described above. When a layer has editor tracking enabled in ArcGIS Online only, the sync process will set the editor tracking values based on the current time stamp and the replica owner (publishing user.)

When collaborating from ArcGIS Online to ArcGIS Enterprise and editor tracking is enabled, all layers from feature layers in ArcGIS Online and ArcGIS Enterprise will have editor tracking enabled.

If you enable editor tracking after adding the feature layer to the collaboration, the receiving organizations will not have editor tracking enabled.

Access control settings are maintained for receiving organizations but have no consequence since all features are owned by the replica owner in the receiving organizations.

Attribute rules

Feature layers you publish from ArcGIS Pro that reference your registered data can include attribute rules. When you edit the feature layer, ArcGIS applies the attribute calculation and constraint rules you defined in the geodatabase. Any time an edit violates one of these rules, the editor receives an error. However, if you edit the data while offline, the attribute rule information is not included in the offline data. When you synchronize the data with the feature layer, the rules are applied at that time. How the violations are treated depends on how the data is registered.

• If you use data that is registered as versioned, attribute rule violations prevent the synchronization process from taking place. Synchronization returns an error when an edit violates an attribute rule. You must correct the violation in the offline version of the data and try to synchronize again.
• If you use archive-enabled, nonversioned data, synchronization completes but edits that violate attribute rules are not applied. Information is written to the ArcGIS Server log for the edits that did not synchronize. If you use nonversioned data and attribute rules, you should always check the ArcGIS Server log after synchronizing to see which (if any) edits were not synchronized. Correct the violation in the offline version of the data and synchronize again.

Hosted feature services

If you are publishing feature services hosted on ArcGIS Online (hosted feature layers), the data is always nonversioned and is automatically prepared to use sync when you enable sync capabilities. This is done because publishers do not have access to the ArcGIS Online hosting server and, therefore, could not manually prepare the data to use sync capabilities.

When you publish hosted feature layers to Portal for ArcGIS, the data is copied to the managed database of the portal's hosting server. This data is also always nonversioned. If your portal's hosting server uses an ArcGIS Data Store relational data store for the managed database, the data is automatically prepared to use sync when you enable sync capabilities. If you are not using a relational data store for the managed database, you may need to alter the data manually to synchronize. For more information, see Enable a hosted feature service for offline mapping in the Portal for ArcGIS help.

Legacy:

ArcGIS Enterprise 10.5.1 was the last release that allows the use of an enterprise geodatabase as the managed database for a hosting server. If you are configuring a new hosting server, use a relational ArcGIS Data Store.

Feature service preparation

When authoring a feature service, the publisher chooses options that define the edits that can be made through the service. The following sections describe how the options are applied when using maps offline.

Operations allowed (capabilities)

Feature service capabilities define the operations that are allowed when working with a feature service. There are two configurations supported for feature services that participate in offline map use:

• Read-only data—If clients will only query the data they download from the feature service to use while offline, set the Query and Sync capabilities on the feature service. With this configuration, the data cannot be edited while offline and synchronized back to the service.
• Editable data—If clients will edit the data when offline and synchronize changes with the feature service when they have connectivity, set the following capabilities on the feature service:
  • Query
  • Sync
  • Any combination of Create, Delete, and Update

Note:

• If the map includes error layers and you enable sync on the feature service, be aware that you should not edit these error layers in the offline map. If you do, the edits will not be applied to the error layers when you synchronize.

• Allowed operations apply only to publishers and users. Server administrators and the service owner have full access to the service with all operations allowed.

  As a result, data that is taken offline by an administrator or the service owner is always editable. If you require read-only offline feature layers, they must be taken offline by a nonadministrative user other than the feature service owner.

When you enable the Sync capability while publishing to the active portal's federated server in ArcGIS Pro, you have additional options when the data is registered as versioned. See Share a web feature layer in the ArcGIS Pro help for information on these options.

Once the feature service is created, publishers and administrators can choose to disable the sync capability. For example, a publisher or administrator can disable the sync capability on the service to prevent clients from synchronizing with the service while data maintenance tasks are in progress, such as rebuilding indexes.

Short transactions

If you are using nonversioned data, avoid keeping edit transactions open for long periods of time when editing a sync-enabled feature service. For example, if you plan to edit nonversioned geodatabase data in ArcGIS Pro that is also used for sync by a feature service, save edits frequently.

Geometry updates and true curves

The feature service can be configured to allow geometry updates and edits to data with true curves. These settings are enforced when edits are synchronized from the client to the service. Any edits the client made that violate the geometry updates and true curve settings of the feature service will not be synchronized with the service.

Ownership-based access control

You can control feature access using ownership-based access control. Any edits the client made that violate the ownership-based access control rules will not be synchronized with the service. The login used to synchronize the edits is considered the editor in this case.

Either the person who took the map offline or an ArcGIS Server administrator can connect to the service and synchronize data. When an administrator synchronizes edits made while offline, ownership-based access control is based on the named user who took the map offline, not the administrator.

Invisible and read-only fields

When you author a feature service, you can choose to make some fields read-only or not visible to the feature service. Fields that are not visible to the feature service will not be downloaded to the client for offline use. Read-only fields will remain read-only in the downloaded data.

Note:

The following must be visible when you enable the sync capability; otherwise, your map cannot be taken offline.

• Subtypes
• The primary and foreign key fields if a relationship class is present
• Editor tracking fields if editor tracking is enabled

Map layers

A feature service published to ArcGIS Server or Portal for ArcGIS that contains two layers based on the same feature class cannot be taken offline, edited, and synchronized.

For example, if you add your roads feature class to your map to display all roads, add the same roads feature class and set a definition query on it to display roads that are under construction, and publish a feature service from the map, you cannot take the feature service offline for editing and synchronize your changes when you are online.

Sync options

When a read-only feature service (only Query and Sync capabilities enabled) contains versioned data, no version is created when you take the data offline. When a client synchronizes with the published version, changes to the published feature service are automatically available in the client.

For editable feature services, sync options and behavior vary depending on whether the data in your service is registered for traditional or branch versioning.

• Publish branch versioned data from ArcGIS Pro—Sync options determine whether a version is created each time a map is taken offline or if no version is created. See Work with offline maps and branch versioned data for a description of scenarios using these options.
• Publish traditional versioned data from ArcGIS Pro—In addition to the options to create no version and creating a version for each map taken offline, you can choose to create a version for each login. See Offline maps and traditional versioned data for descriptions of using different sync options with traditional versioned data.

When a client synchronizes changes to the feature service, edits are applied to the default version if you configured the service so that no version is created. If you configured the service to create a version per map taken offline or per login, edits are synchronized to this version. The geodatabase administrator must perform reconcile and post processes to share the edits.

Note:

The names of versions created for synchronization are limited to 30 bytes.

An administrator of the ArcGIS Server site or the service publisher can alter the sync option for the service in ArcGIS Server Manager.

Follow these steps to change the sync option on a feature service that contains versioned data:

1. Sign in to ArcGIS Server Manager as the service owner or ArcGIS Server administrator.
2. Be sure Services is selected at the top of ArcGIS Server Manager.
3. Browse to the feature service and click the service's name to open information on that service.
4. Click Capabilities.
5. Select Feature Access.
6. Under Properties, click Advanced Options.

   The Feature Service Advanced Options dialog box opens.

7. Under Sync, choose to Create a version for each Downloaded Map or User.
8. Click OK to close the Feature Service Advanced Options dialog box.
9. Click Save and Restart to apply the setting changes to your feature service.

   The service will be unavailable while it is restarting.

Output from downloading local copies of the data or synchronizing with the service

When you download data to a local client, a file that contains the data is created in the ArcGIS Server output directory, and your client downloads that file. By default, any files that have not been accessed by any process for more than 10 minutes are removed from the output directory. If you expect more than 10 minutes will elapse before the client starts downloading the file, you can create another output directory with a longer cleanup time and use this output directory for your feature services. Alternatively, you can increase the cleanup time of the default output directory; however, this affects all services using the default output directory.

Note:

When you use the createReplica operation to create a local copy of the data, you choose the layers, tables, and extent of the data to copy. By default, the local copy includes features that intersect the extent and rows in tables related to these features. For tables, you can choose to apply a query filter or include all rows instead of using the default. When you copy a large amount of data and have many relationship classes, setting a filter or all rows for the tables may improve performance. To set a filter or include all rows, see the layerQueries parameter of the createReplica operation in the ArcGIS REST API help.

Synchronous and asynchronous modes

The sync operations that download local copies of the data or synchronize changes to the service can be run in synchronous or asynchronous mode. When using synchronous mode, the processing is done by the service; therefore, service settings such as the minimum and maximum number of instances used, timeout intervals, and recycling intervals apply. When using the asynchronous mode, the processing is done by the SyncTools geoprocessing service that comes preconfigured with ArcGIS Server; therefore, the settings for the SyncTools geoprocessing service apply.

System information for synchronization processes

When data is downloaded for offline map use or changes are synchronized back to the service, information about these processes is stored in the system tables of the enterprise geodatabase that the feature service is using for its source data. The feature service's replicas resource lists metadata for the feature service. If the service is secured, only metadata associated with the logged in user or anonymous user is listed.

Geodata services also include a replicas resource, which lists metadata for all feature services that reference the geodatabase. Administrators can use geodata services for tasks such as listing metadata per service or removing metadata for feature services that have been removed.