Editor tracking for feature services

Note:

This functionality can only be used with enterprise geodatabases, not databases.

Feature services can track who has made changes to the data and when. This information is stored in fields directly in the dataset.

Editor tracking is a feature of ArcGIS for Desktop that can be utilized by ArcGIS Server to track edits on feature classes and tables. Editor tracking is enabled using ArcGIS for Desktop:

1. In the Catalog tree, right-click any feature class or table and click Manage > Enable Editor Tracking.
2. Review the message prompt and click Yes. This automatically creates fields for tracking edits (if they don't already exist) and enables editor tracking.

You must configure editor tracking settings on each dataset individually. You can choose to create a feature service in which only some of the layers have editor tracking enabled.

When you create a feature service that uses editor tracking, information about editors is automatically recorded in the fields that you defined in ArcGIS for Desktop. If you're tracking who created or edited the data, your application will need to ask for ArcGIS Server credentials at some point so that you can get a token with this information. This token is appended to requests to the feature service in order to communicate who is making requests.

If a nonauthenticated user accesses a feature service with creator tracking enabled, the creator field or date value is left empty for new features and the editor field or date value is set to empty for the last editor.

Editor tracking scenarios

Following are some examples of ways you can use editor tracking settings.

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 your database. You can track the last editor and optionally the last edit date to see who is responsible for specific edits in the current view of the database. If you choose to turn on archiving (requires versioning), you can get the full history of the edits, including deletions and the original creator of the feature.

Depending on your application requirements, the creator of the feature and the feature creation date may or may not be of value in this scenario.

Tracking 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 choose to turn on archiving, you may not need to also track edits to meet these requirements.

Ownership-based access control

You can choose to limit access such that only the user who created a feature can access it. To do this, you need to set the creator field and 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.

Editor tracking in web and desktop clients

Editing layers in web applications with editor tracking enabled is no different than it is for layers that don't have editor tracking enabled. Depending on how the layer was authored with the feature service, the clients either do not see the editor tracking fields or they have a read-only view of them. When edits are sent from the client, information including the web user that has made the edits is included. Depending on which fields are turned on, the web user, as well as the UTC date the changes were applied to the database, is written in the tracking fields. The creator field and creation date field are set only for insertions and are never modified.

Using an integrated security model

If desired, you could implement an integrated security model with feature services, in which an editor in ArcGIS for Desktop is seen as the same editor in web applications. This allows a user named Bob, for example, to make edits in either a desktop session or a web editing application and have the database record the same editor in both environments. To allow this, use the same login information in ArcGIS for Desktop and ArcGIS Server, and do not specify a user realm (described below) in the service.

Using local editing commands

Feature services allow optional editing through local editing commands. With the local editing commands, a replicated copy of the data (child replica) from the server is written to the desktop client. The client then makes edits to the local copy and synchronizes the changes back to the server. The editor and editor dates that are written to the server are based on the user who is logged in to the server to perform the synchronization and the date on which the edit is performed, respectively. The user that was being recorded in the local desktop edit session is ignored by the server.

Editor tracking and time zones

When working with the feature service through REST, all dates are recorded in UTC. When you enable editor tracking on a feature class, make sure that the edits are set to be recorded in UTC. Feature services do not support Database Time as the time zone for tracking edits.

Using a realm with editor tracking

Editor tracking allows you to choose whether you want to append a realm (for example: @esri.com) to the name of the user who makes the edit. Even when you're not using ArcGIS Server, this can be helpful. For example, if you have a user named John in your Denver office and a user named John in your Seattle office, you can track their edits as John@denver and John@seattle, respectively, so that you can be certain which John made each edit.

You can also choose to append a realm to edits made through ArcGIS Server. When you access a secured feature service, ArcGIS Server remembers your user name and applies it to any edits you make with editor tracking. ArcGIS Server also appends any realm you have configured on the feature service.

For example, consider the case that user Mary logs in to ArcGIS Server and makes an edit. The creator is set in the geodatabase as Mary. If you configure the feature service to use the realm @server, subsequent edits appear in the database under the name Mary@server.

To set a realm on a feature service, follow these steps:

In ArcGIS Server Manager

1. Open Manager and log in. If you need help with this step, see Logging in to Manager.
2. Click Services > Manage Services.
3. In the Services module, click the name of your feature service. If you don't see your service in the list, it may be located within a folder in the Site (root) directory.
4. In the Edit module, click Capabilities.
5. Click Feature Access (be careful not to clear the check box).
6. In the Properties section, click Advanced Options.
7. Select Qualify username with realm when applying edits.
8. Choose whether to use the default realm or apply your own.
9. Click OK.

In ArcGIS for Desktop

1. In the Catalog tree, expand the GIS Servers node.
2. Double-click your administrative connection to ArcGIS Server. For instructions on how to connect, see Making an administrative connection to ArcGIS Server in ArcGIS for Desktop.
3. Right-click the feature service's associated map service and choose Service Properties.
4. In the Service Editor dialog box, click the Feature Access tab.
5. Click Advanced Options.
6. In the Feature Service Advanced Options window, select Add realm to user name when applying edits.
7. Choose whether to use the default realm or apply your own.
8. Click OK.

If the server detects that the logged-in user name already includes a realm, the server does not append its own realm.

It's possible to map users between the database and server domains. You might want to do this if users need to make edits directly to the geodatabase in ArcGIS for Desktop and also over the web through a feature service. You would want both environments to log the same user. The workflow to accomplish this is as follows:

1. Set up accounts with matching logins in both ArcGIS for Desktop and ArcGIS Server.
2. Set the database and server to use the same realm or not use a realm at all.