When you download and take offline a map that contains an editable feature service that uses data that is registered for traditional versioning, a new geodatabase version is created from the version used by the published data. When a client synchronizes edits with the feature service, edits are applied to the new 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 version is created when the map is downloaded. Similarly, no 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 version is generated from the published version each time you take offline a map containing an editable feature service. The 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 version name is unique. For example, if user Bob downloads a map that contains the feature service NetFS, the name of the version created could be Bob_NetFS_1404578882000. If the same user downloads the map multiple times (for example, from more than one device), different 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 map versions. As downloaded maps are removed from the application used for offline edits, their versions can be reconciled, posted, and deleted.
Note:
If your feature service was published to an ArcGIS Server site that is not federated with a portal or you access the data without signing in, the name of the map version will be Esri_Anonymous_<feature service name>_<ID>.
Create a version for each user
With this option, a 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 versions are generated. Each version is specific to an individual user, and the 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 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 version was reconciled. A user 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 map version created will be Esri_Anonymous_<feature service name>, and every user connecting to the portal will use the same version.
The option to create a version for each user does not apply to data that is registered as branch versioned.
Example workflows
The following example workflows use the version options described in the previous two sections:
- Download maps for data maintenance
- Download maps for a short-duration project
- Download maps for an ongoing project
The components of each workflow are compared in the following table:
| Download maps for data maintenance | Download maps for a short-duration project | Download maps for an ongoing project | |
|---|---|---|---|
Version from which the feature service is published | |||
Offline version is created for each | Downloaded map | User | User |
Number of 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 offline versions are deleted | Daily | At project completion | Never |
Download maps for data maintenance
This workflow involves a member of the organization using a custom app 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. When back in the office, employees synchronize edits made in the field, remove the map, and reconcile and post the map's version with the default geodatabase version. The process may be repeated several times a day. As each process completes, employees delete the offline map 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 the custom mobile app running on one of the available devices in the office. Before leaving the office, the worker downloads the map to the mobile device. The worker then goes into the field and inspects the requested updates. Corrections are made in the field while not connected to the internal network. 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 version is created for the offline map when the mobile worker downloads the map. This 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 the mobile app. 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 their mobile devices, and go into the field to inspect requested updates. To do this, a worker named Bob starts the mobile app, signs in to the organization from the app, and downloads the offline map and data.
Bob then chooses the extent and the base map resolution for the downloaded map.
When the download process starts, a 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 version will be used when the downloaded map is synchronized.
The data is then downloaded to the device and the mobile app switches the map to reference the local data. At this point, the map can be edited without being on the network.
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 in the mobile app.
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 version.
Now that edits from the field are synchronized with the source, Bob removes the local map from the mobile app and returns the device. The process of removing the local map marks the Bob_NetFS_1404578882000 version as no longer associated with an offline map. Bob then connects to the Bob_NetFS_1404578882000 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 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> version. Each new version will include the latest edits from the default version. These 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.
After Bob's changes are reconciled and posted to the default version, Bob deletes the Bob_NetFS_<ID> versions.
Download maps for a short-duration project
In this example, mobile workers take versioned data offline to make edits. They synchronize their edits in the morning and at the end of the day. A nightly reconcile and post process runs to keep the mobile workers' 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 worker 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 a custom mobile app.
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 named Inspection and changes the map to reference this version.
Next, the project manager publishes an InspectionFS feature service 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 version for that worker. This version is used when the worker synchronizes edits.
Create a web map
After 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.
Download the web map
Each mobile worker accesses the web map by signing in to their organizational accounts from a custom mobile app and downloading the web map that has the offline mode enabled.
In the following diagram, one of the mobile workers (Joe) starts the download process while connected to the internal network.
Joe chooses the extent and the base map resolution for the map.
When the download process starts, a 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 version name is based on the mobile worker's login (Joe) and the name of the service from which it was created (InspectionFS). This 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 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 version are visible in the map.
Once the map and data are downloaded, the mobile app switches the map to reference the local data. At this point, Joe can edit the map without being on the network.
A second mobile worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS 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 mobile device and synchronizes with the feature service. This applies the edits to the Joe_InspectionFS 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 version with the Inspection version. The process applies a conflict 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. When validation completes, the process reconciles the mobile worker 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. When 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 the mobile app. When the local maps are removed from the mobile app, the mobile workers' 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' versions and deletes each of these 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.
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. However, in this workflow, the project is ongoing so 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.
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 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 named Inspection and changes the map to reference this version.
Next, the project manager publishes an InspectionFS feature service from ArcGIS Pro.
The project manager checks the Sync capability in the Service Editor in ArcGIS Server Manager, 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 version is created for that worker. This 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 version for that worker. This version is used when the worker synchronizes edits.
Create a web map
After 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.
Download the web map
Each mobile worker accesses the web map by signing in to their organizational accounts from a custom mobile app and downloading the web map that has the offline mode enabled.
In the following diagram, one of the mobile workers (Joe) starts the download process while connected to the internal network.
Joe chooses the extent and the resolution for the map.
When the download process starts, ArcGIS creates a version (Joe_InspectionFS) from the published version in the source geodatabase. Because the feature service was set to create a version for each user, the version name is based on the mobile worker's login (Joe) and the name of the service from which it was created (InspectionFS). This 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 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 version appear in the map.
After the data and map are downloaded, the mobile app switches the map to reference the local data. At this point, Joe can edit the map without being on the network.
A second mobile worker (Mary) performs the same steps as Joe. This results in a Mary_InspectionFS 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.
When the field device is connected to the network at the end of the day, Joe synchronizes with the feature service. This applies the edits to the Joe_InspectionFS 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 version with the Inspection version. The process applies a conflict 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 version includes Joe's edits but the Joe_InspectionFS version does not include Mary's edits. This is because the Joe_InspectionFS version was reconciled and posted before the Mary_InspectionFS 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 version is reconciled a second time with the Inspection version to finish the automated process. Each mobile worker's 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 versions remain as long as Joe and Mary continue to perform sensor inspections. If at some point they stop working on the project, the versions can be removed after Joe and Mary perform a final synchronization and unregister their local maps, and final reconcile and post processes have been performed on the Joe_InspectionFS and Mary_InspectionFS versions.