When you download and take offline a map that contains an editable feature service that uses data that is registered for traditional versioning, a replica version is created from the version used by the published data and a feature service replica is created and associated with the replica version. When a client synchronizes edits with the feature service replica, edits are applied to the replica version. As a result, you must perform additional reconcile and post processes to get the edits into the published version and share the edits with others.
If the map contains a read-only feature service (only query and sync are enabled on the feature service), and the feature service contains versioned data, no replica version is created when the map is downloaded. Similarly, no replica version is created when data is copied during distributed collaboration workflows. When clients synchronize with the feature service in these cases, they have access to any edits made to the source data.
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.
The two options described below allow the feature service owner or ArcGIS Server administrator to choose how traditional versions are created for a particular editable feature service. The publisher sets these options when publishing the feature service.
Create a version for each offline map
This is the default option. With this option, a replica version is generated from the published version each time you take offline a map containing an editable feature service. The replica version name includes the following:
- The name of the user who downloads the map
- The name of the feature service
- A unique identifier (ID)
These three components ensure that the replica version name is unique. For example, if user Bob downloads a map that contains the feature service NetFS, the name of the replica version created could be Bob_NetFS_1404578882000. If the same user downloads the map multiple times (for example, from more than one device), different replica versions are used when the user synchronizes from each device. Any one device will not have access to edits from the other devices. However, newly downloaded maps will be current with the published version. If there are many downloaded maps, there will be many replica versions. As downloaded maps are removed from the application used for offline edits, their replica versions can be reconciled, posted, and deleted.
Note:
If you published the sync-enabled feature service to a stand-alone ArcGIS Server site that does not have individual user accounts, the name of the replica version will be Esri_Anonymous_<feature service name>_<ID>.
Replica version names are limited to 30 characters. The feature service portion of the name will be truncated to meet this limit.
Create a version for each user
With this option, a replica version is generated for each user who downloads a map containing an editable feature service. For example, if 10 users download the same map, 10 replica versions are generated. Each replica version is specific to an individual user, and the replica version name is composed of the user name and service name (for example, Joe_InspectionFS). If a user downloads the map multiple times (for example, from more than one device), the same replica version is used when the user synchronizes from each device. Any one device has access to edits from the other devices. However, newly downloaded maps will only be as up to date as the last time the user's replica version was reconciled. A user's replica version remains as long as the user has a map downloaded.
Note:
If you use this option, either federate your ArcGIS Server site with a portal or configure user accounts in ArcGIS Server. If you do not do this, the name of the replica version created will be Esri_Anonymous_<feature service name>, and every user connecting to the portal to take the web map containing the feature service offline will use the same replica version.
Example workflows
The following example workflows use the version options described in the previous two sections:
- Workflow 1: Download maps for data maintenance
- Workflow 2: Download maps for a short-duration project
- Workflow 3: Download maps for an ongoing project
The components of each workflow are compared in the following table:
| Workflow 1 | Workflow 2 | Workflow 3 | |
|---|---|---|---|
Geodatabase version from which the feature service is published | |||
Replica version is created for each | Downloaded map | User | User |
Number of replica versions created | Many | Few | Few |
Latency between offline edits and updates to the default version | Low | High (1 week) | High (Daily) |
Maps involved in quality assurance | One map | All maps | All maps |
Frequency that replica versions are deleted | Daily | At project completion | Never |
Workflow 1: Download maps for data maintenance
This workflow involves a member of the organization using ArcGIS Field Maps in the field to confirm edits provided from marked up maps. In this case, the data is registered to participate in traditional versioning and the workers require the map they download to have the latest data from the default version in the geodatabase. Once back in the office, employees synchronize edits made in the field, remove the map, and reconcile and post the map's replica version with the default geodatabase version. The process may be repeated several times a day. As each process completes, employees delete the replica version.
To do this, a web map is available in the company's organizational account for members of the office workers group. A worker who is a member of this group can access the web map using Field Maps running on one of the available devices in the office. Before leaving the office, the worker downloads the map using Field Maps. The worker then goes into the field and inspects the requested updates. Corrections are made in the field using Field Maps. When back in the office, the worker's corrections are synchronized with the feature service, and reconciled and posted with the default version.
The following sections describe this workflow:
Publish a feature service
To create the web map, a feature service must first be published.
The publisher starts ArcGIS Pro and adds data from the default version to a map. In this example, the data includes new sensors from a feature class in the company's enterprise geodatabase. The feature class is registered as versioned.
The publisher publishes a feature layer named NetFS that references registered data from ArcGIS Pro.
During the publishing process, the publisher edits the following settings on the feature layer Configuration tab to allow the layer to be taken offline and edited:
- Enable editing and allow editors to: > Add, update, and delete features—Allows full editing of the data.
- Enable Sync—Allows the layer to be taken offline.
- Sync > Create a version for each downloaded map—A uniquely named replica version is created for the offline map when the mobile worker downloads the map. This replica version is then used when the worker synchronizes edits.
The publisher also shares the service with the office workers group so data can be accessed by others in the organization.
Create a web map
The next step after creating a feature service is to create a web map. The publisher does this by signing in to the organization (ArcGIS Enterprise or ArcGIS Online), creating a web map, adding the feature layer to the map, and sharing the map with the office workers group. The web map's offline mode property is enabled, making it available for offline use in Field Maps. Members of the office workers group can now download the map.
Download the web map
With the web map available to them, workers can download it to Field Maps, and go into the field to inspect requested updates. To do this, a worker named Bob starts Field Maps and signs in to the organization. The newly shared web map appears.
Because the web map has offline mode enabled, it appears in Field Maps with a download button. Bob clicks the download button to start the download process.
Bob then chooses the extent and the base map resolution for the downloaded map.
When the download process starts, a replica version named Bob_NetFS_1404578882000 is created from the published version (default) in the backend geodatabase. Because the service was set to create a version for each downloaded map, a unique version name is generated. The name is composed of the mobile worker's login (Bob), the feature service name (NetFS), and a unique ID. This replica version will be used when the downloaded map is synchronized.
The data is then downloaded to the device. Once downloaded, Field Maps switches the map to reference the local data. At this point, the map can be edited without being on the network. A sync button appears on the map in Field Maps to indicate that it is referencing the local data.
Synchronize edits
While in the field, Bob notices that one of the sensors is incorrectly positioned on the wrong side of the street. Bob makes this correction using Field Maps.
During the day, Bob may visit other locations and make other corrections. If connectivity is available, Bob may also sync the edits from the field. When back in the office, Bob connects to the internal network on the field device and performs a final synchronization. This ensures that all corrections made in the field are applied to the Bob_NetFS_1404578882000 replica version.
Now that edits from the field are synchronized with the source, Bob removes the local map from Field Maps and returns the device. The process of removing the local map marks the Bob_NetFS_1404578882000 replica version as no longer associated with an offline map. Bob then connects to the Bob_NetFS_1404578882000 replica version in ArcGIS Pro and reconciles and posts it with the default version. Bob uses attribute-based conflict detection and manually resolves any conflicts.
After the edits are saved and Bob switches back to the default version, Bob deletes the Bob_NetFS_1404578882000 replica version.
Bob discovers that more trips to the field are necessary to properly update the data. Each trip to the field requires a new downloaded map and a new Bob_NetFS_<ID> replica version. Each new replica version will include the latest edits from the default version. These replica versions will remain in the geodatabase until they are disassociated with a map, reconciled, and posted.
In addition to Bob, other office workers can perform similar tasks at the same time as Bob.
Once Bob's changes are reconciled and posted to the default version, Bob deletes the Bob_NetFS_<ID> replica versions.
Workflow 2: Download maps for a short-duration project
In this example, mobile workers take versioned data offline to make edits. The versioned data in the source geodatabase references a project version that is a child of the default version.
Mobile workers synchronize their edits in the morning and at the end of the day with the project version. A nightly reconcile and post process runs to keep the mobile workers' replica versions up to date with edits made by other mobile workers. When each mobile worker synchronizes the next morning, each sees the edits made by other mobile workers. When the project is complete, all edits from the field have been synchronized and applied to the project version. The project version is then reviewed and reconciled and posted with the default geodatabase version. Upon project completion, an employee deletes the feature service and the mobile workers' replica versions.
In this workflow, the latency of the mobile workers' data is no more than one week.
The following describes the steps needed to complete this workflow:
- Publish a feature service
- Create a web map
- Download the web map
- Synchronize edits
- Run nightly geodatabase processing
- Delete offline maps and perform final reconcile and post processes
Publish a feature service
In this example, a project manager needs to deploy workers to the field to perform sensor inspections. Sensor inspections are carried out periodically throughout the year. During inspections, mobile workers check for and record things like damage and accessibility of the sensors. This information is used to plan repairs and to understand which sensors can be accessed easily. The project is scheduled to occur over a time period of one week. For the data collection, each mobile worker has been provided a tablet running Field Maps.
For this project, the project manager plans to create and share a web map for sensor inspections in the company's organizational account. The web map will reference a feature service running in the company's on-premises ArcGIS Server site.
To create the feature service, the project manager adds the sensor feature class from the default version of the source enterprise geodatabase to a map in ArcGIS Pro. The feature class has been registered for traditional versioning. The sensors that are flagged for inspection are colored yellow.
To organize the work, the project manager creates a version from the default geodatabase version. The manager names the child version Inspection and changes the map to reference this version.
Next, the project manager publishes a feature service named InspectionFS from ArcGIS Pro.
During the publishing process, the project manager edits the following settings on the feature layer Configuration tab to allow the layer to be taken offline and edited:
- Enable editing and allow editors to: > Add, update, and delete features—Allows full editing of the data.
- Enable Sync—Allows the layer to be taken offline.
- Sync > Create a version for each user—The first time a mobile worker downloads a map, ArcGIS creates a replica version for that worker. This replica version is used when the worker synchronizes edits.
Create a web map
Once the feature service has been published, the project manager creates a web map in the ArcGIS Enterprise portal and shares it with a group of which all the mobile workers are members.
The project manager performs these steps:
- Sign in to the organization.
- Create a web map.
- Add the newly published feature service to the web map.
- Save the web map.
- Share the web map and the feature service with the group that includes the mobile workers.
- Enable the offline mode property on the web map to make it available for offline use in Field Maps.
Download the web map
Each mobile worker accesses the web map by signing in to their accounts with Field Maps.
With the web map available, each mobile worker starts Field Maps and signs in to the organization. The newly shared web map appears.
Because the web map has offline mode enabled, it appears in Field Maps with a download button (the cloud with an arrow). One of the mobile workers (Joe) clicks the download button to start the download process.
Joe chooses the extent and the base map resolution for the map.
When the download process starts, a replica version is created from the published version in the source geodatabase called Joe_InspectionFS. Because the feature service was set to create a version for each user, the replica version name is based on the mobile worker's login (Joe) and the name of the service from which it was created (InspectionFS). This replica version will be used when the downloaded map is synchronized.
Note:
Any time Joe downloads a map from the InspectionFS service, it will reference the Joe_InspectionFS replica version. For example, at some point, Joe may need to remove the local map and re-create it with a larger extent. When Joe downloads the map again, all the edits that Joe previously synchronized from the Joe_InspectionFS replica version are visible in the map.
Once the map and data are downloaded, Field Maps switches the map to reference the local data. At this point, Joe can edit the map without being on the network. A Sync button appears on the map in Field Maps to indicate that it is referencing the local data.
A second mobile worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS replica version being created in the source geodatabase.
Synchronize edits
While in the field, Joe is assigned work on the east side of the map. Joe updates sensor feature statuses while performing inspections. If the sensor passes inspection, it appears green. If it is damaged and requires repair, it appears red.
At the end of the day, Joe connects to the network from the field device and clicks the Sync button in Field Maps. This applies the edits to the Joe_InspectionFS replica version in the source geodatabase.
At the end of the day, Mary also synchronizes her sensor inspections from the west side of the map.
Run nightly geodatabase processing
In the evening, an automatic process runs to reconcile and post the mobile workers' edits. The process first reconciles and posts each replica version with the Inspection version. The process applies a conflict resolution policy wherein the last edit in is preserved and conflict detection is attribute based.
When all the edits from the field are applied in the Inspection version, validation scripts run on the data. These scripts identify and correct edits with invalid values or out of bounds features. For example, the status field must have a valid status value. If the value is invalid, it is set back to needs inspection, which is symbolized with yellow points. Once validation completes, the process reconciles the mobile worker's replica versions with the Inspection version so each has the latest changes.
When Joe and Mary synchronize the next morning, they see each other's updates.
Note:
The nightly process could have also reconciled with the default version to include edits that were made to the default version since the start of the project. Instead, the project manager chose to only reconcile with the default version at the end of the project. This allows conflicts to be detected and manually reviewed before posting to the default version. If this process is done before the end of the project, workers can perform additional edits to these features that will not appear as conflicts on the final reconcile process.
Also note that in this example, the automated process to reconcile and post the mobile workers' edits runs nightly. This means that a mobile worker won't see the most recent edits made by others until the next day. To decrease this latency, the process can be run more frequently. For example, if it were run hourly, a mobile worker could synchronize on the hour to get the latest edits made by others.
Delete downloaded maps and perform final reconcile and post processes
The process described above continues through the one-week time frame of the project. Once all sensors have been inspected, the project is complete. Mobile workers are asked at the end of the project to synchronize the last of their edits and remove the local map from Field Maps. Once the local maps are removed from Field Maps, the mobile workers' replica versions are no longer associated with a downloaded map. The project manager then stops and deletes the feature service.
The project manager runs final reconcile and post processes on all the mobile workers' replica versions and deletes each of these replica versions. The project manager then reconciles and posts the Inspection version with the default version. The project manager manually reviews and resolves conflicts during this process. When complete, the latest sensor inspection information is available to all workers in the default version. The final step the project manager completes is to delete the Inspection version.
Workflow 3: Download maps for an ongoing project
This example workflow is similar to the previous workflow (Download maps for a short-duration project) in that mobile workers synchronize edits they made while offline. They connect to the network and synchronize in the morning and at the end of the day. Similar to the previous workflow, in this workflow, the feature service is published from a quality assurance version rather than directly from the default version. That means additional review, reconcile, and post processes are required. Unlike the previous workflow, though, the quality assurance version remains in the geodatabase; it is not limited to the life of a project.
The following are the steps needed to complete this workflow:
- Publish a feature service
- Create a web map
- Download the web map
- Synchronize edits
- Run nightly geodatabase processing
Publish feature service
For this project, the project manager creates and shares a web map for sensor inspections in the company's organizational account. The web map references a feature service running on the company's on-premises ArcGIS Server.
To create the feature service, the project manager adds the sensor feature class from the default version of the source enterprise geodatabase to a map in ArcGIS Pro. The feature class has been registered for traditional versioning. The sensors that are flagged for inspection are colored yellow.
To organize the work, the project manager creates a child version from the default version, and names the child version Inspection. The manager changes the map to reference the Inspection version.
Next, the project manager publishes a feature service named InspectionFS from the map in ArcGIS Pro.
The project manager checks the Sync capability in the Service Editor because the service is intended to be used in an offline map. The project manager also clicks Advanced Options to display Feature Service Advanced Options.
In Feature Service Advanced Options, the project manager chooses the Create a version for each user option. With this option, the first time a mobile worker downloads a map, a replica version is created for that worker. This replica version is then used when the worker synchronizes edits.
During the publishing process, the project manager edits the following settings on the feature layer Configuration tab to allow the layer to be taken offline and edited:
- Enable editing and allow editors to: > Add, update, and delete features—Allows full editing of the data.
- Enable Sync—Allows the layer to be taken offline.
- Sync > Create a version for each user—The first time a mobile worker downloads a map, ArcGIS creates a replica version for that worker. This replica version is used when the worker synchronizes edits.
Create a web map
Once the feature service has been published, the project manager creates a web map in the ArcGIS Enterprise portal and shares it with a group of which all the mobile workers are members.
The project manager performs these steps:
- Sign in to the organization.
- Create a web map.
- Add the newly published feature service to the map.
- Save the web map.
- Share the web map and the feature service with the group that includes the mobile workers.
- Enable the offline mode property on the web map to make it available for offline use in Field Maps.
Download the web map
Each mobile worker accesses the web map by signing in to their accounts with Field Maps.
With the web map available, each mobile worker starts Field Maps and signs in to the organization. The newly shared web map appears.
The web map has offline mode enabled, so it appears in Field Maps with a download button (the cloud with an arrow). One of the mobile workers (Joe) clicks the download button to start the download process.
Joe chooses the extent and the resolution for the map.
When the download process starts, ArcGIS creates a replica version (Joe_InspectionFS) from the published version (Inspection) in the source geodatabase. Because the feature service was set to create a version for each user, the replica version name is based on the mobile worker's login (Joe) and the name of the service from which it was created (InspectionFS). This replica version will be used when the map is synchronized.
Note:
Any time Joe downloads a map from the InspectionFS service, it will reference the Joe_InspectionFS replica version. For example, at some point, Joe may need to remove the local map and re-create it with a larger extent. When Joe downloads the map again, all the edits that were synchronized from the Joe_InspectionFS replica version appear in the map.
Once the data and map are downloaded, Field Maps switches the map to reference the local data. At this point, Joe can edit the map without being on the network. A Sync button appears on the map in Field Maps to indicate that it is referencing the local data.
A second mobile worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS replica version being created in the source geodatabase.
While Mary and Joe edit in the field, a new sensor is added to the default geodatabase version by an office worker. The new sensor is the result of a new project in the area. Whenever new sensors are installed, an inspection is required, thus it appears yellow.
Synchronize edits
While in the field, Joe is assigned work on the east side of the map. Joe updates the status of each sensor feature during the sensor inspection. If the sensor passes inspection, it appears green. If it is damaged and requires repair, it appears red.
Once the field device is connected to the network at the end of the day, Joe clicks the Sync button in Field Maps. This applies the edits to the Joe_InspectionFS replica version in the source geodatabase.
At the end of the day, Mary also synchronizes her sensor inspections from the west side of the map.
Run nightly geodatabase processing
In the evening, an automatic process runs to reconcile and post the mobile workers edits. The process first reconciles and posts each mobile worker's replica version with the Inspection version. The process applies a conflict resolution policy wherein the last edit in is preserved and conflict detection is attribute based.
When all edits from the field are applied in the Inspection version, validation scripts are run on the data in the Inspection version. These scripts identify and correct edits with invalid values or out of bounds features.
Note:
At this point in the process, the Mary_InspectionFS replica version includes Joe's edits but the Joe_InspectionFS replica version does not include Mary's edits. This is because the Joe_InspectionFS replica version was reconciled and posted before the Mary_InspectionFS replica version.
The next step in the automatic process involves reconciling and posting the Inspection version with the default version. The process uses attribute-based conflict detection and automatically resolves conflicts. The reconcile process brings the edits from the default version (the new sensor) into the Inspection version, while the post process applies the edits from the Inspection version (Joe and Mary's edits) to the default version.
Each mobile worker's replica version is reconciled a second time with the Inspection version to finish the automated process. Each mobile worker's replica version is now up to date.
Tip:
To get the latest changes to the mobile workers, the reconcile process is needed but the post process is not required. Some organizations may run a separate process to post edits to the default version, as this makes the edits available to others outside the project.
The next morning when Joe and Mary synchronize, they see the updated sensors from the other mobile workers and the new sensor from the default version. The new sensor is on the east side of the map, so Joe will inspect the new sensor and synchronize the results. The next day, after the nightly processes are run, Joe's inspection information for the new sensor will be in the default version.
This process repeats continuously on a day-to-day basis. The Joe_InspectionFS and Mary_InspectionFS replica versions remain as long as Joe and Mary continue to perform sensor inspections. If at some point they stop working on the project, the replica versions can be removed once Joe and Mary have done a final synchronization and unregistered their local maps, and final reconcile and post processes have been performed on the Joe_InspectionFS and Mary_InspectionFS replica versions.