ArcGIS Server feature services provide a way to share your data over the web and allow users to edit this data when they connect to the feature service. If the data in the feature service has editor tracking enabled, ArcGIS Server records who adds or edits the data through the feature service and when the edit is made. This information is stored in fields that the data owner defines when enabling editor tracking on the source data.
Because editor tracking is enabled on a per-feature class or per-table basis, you can enable editor tracking for some or all of the layers in a feature service using one of the following methods:
- Use the Enable Editor Tracking geoprocessing tool in ArcGIS Pro or call the tool from a Python script on an ArcGIS Server machine.
- Connect to the geodatabase feature class or table in the Catalog pane in ArcGIS Pro and enable editor tracking from the Manage context menu.
Note:
- You can only enable editor tracking on data in enterprise geodatabases, not databases.
- Only the owner of the feature class or table can enable editor tracking.
- If you enable editor tracking on the source feature class and tables after publishing the feature service, restart the feature service.
When an authenticated user edits a feature service that contains layers with editor tracking enabled, the login used to connect to the ArcGIS Server site is recorded in the creator and editor fields, and the date and time the feature was added or edit was made is recorded in the creation and editing date fields, respectively.
If a nonauthenticated user edits a feature service that has editor tracking enabled, ESRI_Anonymous is recorded in the creator and editor fields, and the corresponding date the feature was created or edited is set in the geodatabase. However, when you view these fields from the feature service, they appear empty.
If you add an unsecured feature service to ArcGIS Online or an ArcGIS Enterprise portal (in other words, no ArcGIS Server credential is provided for the service), edits are considered to be from a nonauthenticated user and ESRI_Anonymous is recorded in the creator and editor fields.
Dive-in:
To track who created or edited the data, your application must request ArcGIS Server credentials so you can get a token with this information. This token is appended to requests to the feature service to communicate who is making requests.
Reasons to use editor tracking
The following are examples of why you'd use editor tracking.
Accountability and quality control
Tracking who made edits and when the edits were applied can help you enforce accountability and quality control of the features you add to the geodatabase. You can track who creates features, the last editor, and the last edit date to see who is responsible for specific edits to existing features. If you turn on archiving, you can get the full history of the edits, including deletions.
Apply ownership-based access control
You can limit access such that only the user who created a feature can access it. To do this, you must configure the service to enforce access based on who created the feature. This is discussed in more detail in Ownership-based access control for feature services.
Track changes through time
To learn the volume of edits over time, you can track the last edit date and the creation date. This can help you identify trends and make correlations with the date. If you enable archiving, you may not need to also track edits to meet these requirements.
Editing feature services when not connected to the network
If you configure the data and feature service to take the feature service offline, a replicated copy of the data (child replica) is created on the machine or device that runs the app you use to take the feature service offline. Edits are made to the local copy and synchronized back to the ArcGIS Server site when the app user connects to the network. To understand how editor tracking fields are populated in this scenario, see Prepare feature services for offline use.
Editor tracking and time zones
When working with the feature service through REST, all dates are recorded and returned in UTC. When you enable editor tracking on a feature class, it is recommended that you configure the date fields used to record edits to use UTC.
If you cannot use UTC for the date fields that track edits—for example, the fields are used by other applications that prevent you from using UTC—specify the time zone used in the database when you publish a feature service.