To share ArcGIS Server feature services with an ArcGIS Online organization or an ArcGIS Enterprise organization other than your own, you can share the feature service in a distributed collaboration. To do this, you must enable synchronization (sync) on the feature service.
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.
All the data in the map from which you publish must be configured the same; you cannot have a combination of versioned and nonversioned data or a combination of traditional and branch versioned data in the map.
Data preparation requirements vary depending on whether the data that the service references is versioned and the type of collaboration workflows you will use. These data and collaboration workflow requirements also affect the settings you configure on the feature service when you publish it. The following sections discuss these requirements.
Scenario 1: The data isn't versioned and edits made by the collaboration host and participants will be shared
If the data you will share in a distributed collaboration has not been registered for traditional or branch versioning, you must enable archiving on the data and publish a sync-enabled, ArcGIS Server feature service to share it in a distributed collaboration. To support two-way sharing of edits in the collaboration, the data must also have replica tracking enabled.
To use nonversioned data in a distributed collaboration that allows edits from collaborators to be sent to the host and edits from the host to be sent to collaborators, the data and publishing settings described in the sections below are required.
Data requirements for this scenario
Configure the following before you publish:
- All the data in the map must be from the same enterprise geodatabase, and the data must be registered with the geodatabase.
- All the feature classes to be published must have archiving enabled.
- Each feature class to be published must contain a global ID field.
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 on the feature class, feature dataset, and table context menus in the Catalog tree.
- All the feature classes to be published must have replica tracking enabled.
If you publish from ArcGIS Pro 2.7 or later and you enable sync when you publish to ArcGIS Enterprise 10.9 and later, the data will have replica tracking enabled automatically. For all other cases, enable replica tracking on the data before you publish. Use the Enable Replica Tracking geoprocessing tool or right-click the dataset in the Catalog pane in ArcGIS Pro, click Manage, and click Replica Tracking.
- If the datasets to be published participate in a relationship class or have attachments, those relationships must use a global ID primary key.
If the object ID 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 object ID-based relationship classes and attachments to use global ID fields as the primary key.
- The following fields must be included in the feature service; you cannot hide these columns in any of the feature classes to be published: fields that have subtypes, the primary and foreign key fields for the relationship class or attachments, editor tracking fields (if editor tracking is enabled on the dataset).
- The login account specified in the database connection used to access the data must be granted the privileges on the data in the geodatabase that allows them to perform the editing operations configured for the feature service.
Feature service configuration
When you publish the feature layer, you must set the following on the Configure Web Layer Properties dialog box, accessed from the Configuration tab of the Share As Web Layer pane:
- Enable editing on the feature service and choose the level of editing allowed.
- Enable sync.
- Set the sync option to None.
Scenario 2: The data is registered for branch versioning and edits made by the collaboration host and participants will be shared
If you use branch versioning to manage editing workflows and require that edits are shared between the collaboration host and participants (bidirectional editing), the data and feature service must meet the requirements described in the sections below.
Note:
Advanced geodatabase dataset types—such as parcel fabrics, topologies, and utility networks—cannot be shared in a collaboration.
This scenario is supported with ArcGIS Pro 2.7 and later and ArcGIS Enterprise 10.9 and later.
The names of versions created for synchronization are limited to 30 bytes.
Data requirements for this scenario
Configure the following before you publish:
- All the data in the map must be from the same enterprise geodatabase, and the data must be registered with the geodatabase.
- All the feature classes to be published must be registered for branch versioning, which requires each feature class to have a global ID field.
- The following fields must be included in the feature service; you cannot hide these columns in any of the feature classes to be published: fields that have subtypes, the primary and foreign key fields for the relationship class or attachments, editor tracking fields (if editor tracking is enabled on the dataset).
- The login account specified in the database connection used to access the data must be granted the privileges on the data in the geodatabase that allows them to perform the editing operations configured for the feature service.
Feature service configuration
When you publish the feature layer, you must set the following on the Configure Web Layer Properties dialog box, accessed from the Configuration tab of the Share As Web Layer pane:
- Enable editing on the feature service and choose the level of editing allowed.
- Enable sync.
- Use the default sync option for version creation.
Do not use the None option; it will cause the collaboration to fail.
Scenario 3: The data is registered for traditional versioning and edits will be shared one way
If your organization requires the use of traditional versions because you use a quality assurance version of the data, data and services must meet the requirements described in this section.
This scenario is supported with ArcGIS Pro 2.7 and later and ArcGIS Enterprise 10.9 and later.
Data that is registered for traditional versioning cannot participate in bidirectional editing workflows. That means edits are always made in one organization and pushed to other members of the collaboration. For example, the collaboration host can push edits to participants.
The data and feature service settings described in the sections below are required for this scenario.
Data requirements for this scenario
Configure the following before you publish:
- All the data in the map must be from the same enterprise geodatabase, and the data must be registered with the geodatabase.
- All the feature classes to be published must be registered for full traditional versioning; the registration option to move edits to base is not supported.
- Each feature class to be published must contain a global ID field.
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 on the feature class, feature dataset, and table context menus in the Catalog tree.
- If the datasets to be published participate in a relationship class or have attachments, those relationships must use a global ID primary key.
If the object ID 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 object ID-based relationship classes and attachments to use global ID fields as the primary key.
- The following fields must be included in the feature service; you cannot hide these columns in any of the feature classes to be published: fields that have subtypes, the primary and foreign key fields for the relationship class or attachments, editor tracking fields (if editor tracking is enabled on the dataset).
- The login account specified in the database connection used to access the data must be granted the privileges on the data in the geodatabase that allows them to perform the editing operations configured for the feature service.
Feature service configuration
When you publish the feature layer, you must set the following on the Configure Web Layer Properties dialog box, accessed from the Configuration tab of the Share As Web Layer pane:
- If editing is enabled on the feature service, the login account specified in the database connection used to access the data must be granted the privileges on the data in the geodatabase that allows them to perform the editing operations configured for the feature service. If editing is not enabled on the feature service, the login account must have privileges to select the data included in the feature service.
- Enable sync.
- Use the default sync option for version creation.
Do not use the None option; it will cause the collaboration to fail.
Scenario 4: The feature service will be shared as a reference
When a feature service is shared with collaborating portals as a reference, members of the collaborating organization cannot edit the feature service.
The data and feature service settings described in the sections below are required for this scenario.
Data requirements for this scenario
Configure the following before you publish:
- All the data in the map must be from the same enterprise geodatabase, and the data must be registered with the geodatabase.
- If the data is registered for traditional versioning, it must be registered for full versioning; it cannot be registered with the option to move edits to base.
- Each feature class to be published must contain a global ID field.
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 on the feature class, feature dataset, and table context menus in the Catalog tree.
- If the datasets to be published participate in a relationship class or have attachments, those relationships must use a global ID primary key.
If the object ID 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 object ID-based relationship classes and attachments to use global ID fields as the primary key.
- The following fields must be included in the feature service; you cannot hide these columns in any of the feature classes to be published: fields that have subtypes, the primary and foreign key fields for the relationship class or attachments, editor tracking fields (if editor tracking is enabled on the dataset).
- The login account specified in the database connection used to access the data must have privileges to select the data that will be published.
Feature service configuration
When you publish the feature layer, you must set the following on the Configure Web Layer Properties dialog box, accessed from the Configuration tab of the Share As Web Layer pane:
- Do not enable editing on the feature service.
- Enable sync.
- Use the default sync option for version creation.