Conflict prevention improves support for a multiuser enterprise geodatabase LRS Network and event editing by coordinating route and event edits. With the ability to lock routes or events on routes to a specific person in a named geodatabase version, edit conflicts can be avoided.
Conflict prevention scenarios
Scenarios where conflict prevention is useful include the following:
- Route edits versus event edits—In this scenario, a person is editing a route and changing the measures on the route in one version, and someone else is editing measures on events located on that route in another version.
Without conflict prevention, on reconcile and post, ArcGIS will not detect that the measures on the events may not be relevant to the new measures on the route, or vice versa. By allowing you to lock routes, entry of the measures for events and routes is coordinated to prevent this situation. This alleviates the need for others, either LRS or event editors, to resolve measure-based mismatches and conflicts.
- Route edits versus route edits—In this scenario, someone is editing a route in one version while someone else is editing the same route in a different version.
Without conflict prevention, on reconcile and post, the last person to reconcile must manually reconcile all conflicts in the route table, centerline sequence table, calibration point feature class, and centerline feature class. In addition, the last person to reconcile needs to reconcile any conflicts related to event measures behaviors in all event layers. If someone makes an error in reconciliation, the route measures or event measures could be incorrect. By allowing you to lock routes to edit, this scenario is avoided.
- Event edits versus event edits—In this scenario, someone is editing an event on a route in one version while someone else is editing the same event on the same route in another version.
The second person to post edits must manually resolve all conflicts. Enabling conflict prevention allows you to lock that event on the route and make and post edits before someone else can make edits to the events on the same route.
In some of these scenarios, without conflict prevention enabled, editors may need to resolve measure discrepancies. These measure discrepancies may not be detected by ArcGIS as conflicts in all cases.
In some cases, these conflicts or discrepancies may be on events managed by different business units, and the editor resolving the discrepancies may not have the knowledge needed to do so. In other cases, someone may be placed in the position of resolving conflicts in Roads and Highways schema elements, such as the centerline sequence table. Resolving these conflicts would require maintaining consistency between five or more tables and feature classes and could be error prone. Enabling conflict prevention in Roads and Highways can prevent placing others in these type of situations.
Lock types
When conflict prevention is enabled, two different types of locks are used during network and event editing.
- Route locks—When editing in ArcMap using Roads and Highways for Desktop, you can lock routes in the version of the geodatabase being edited. These route locks are created by a single person in a single version of the geodatabase. Once a route is locked, only the person who locked the route can edit the route and events on the route in the version of the geodatabase for which the lock was acquired. The route with the route lock would not be able to be edited by someone else or in another version until the route lock is released. When someone posts edits from the version of the geodatabase with the route lock to the lock root version, the lock on the route is removed.
- Event locks—When editing in the Event Editor, you can lock one or more events on a route in the version of the geodatabase being edited. Event locks are created for each event on each route being edited by someone in a single version of the geodatabase. Once an event is locked on a route, only the person who locked the event can edit the event in the version of the geodatabase for which the lock was acquired. The event with the event lock would not be able to be edited by someone else or in another version until the lock is released. When the person with the event lock posts edits from the version of the geodatabase with the event lock to the lock root version, the event lock is removed. Event locks are different from route locks because they are acquired for each event in a network. This allows people from different business units to edit different event layers on the same route in different versions of the geodatabase at the same time. Additionally, a route lock cannot be acquired on a route with an event lock, unless the person with the event lock is attempting to acquire the route lock.
Lock root version
When enabling conflict prevention, the lock root version of the geodatabase must be configured. The lock root version is the top version of the geodatabase version tree to which edits in Roads and Highways will be posted. This version could be the default or another version that is a descendent of the default version. 
Editing with conflict prevention enabled
The experience for editing routes and events in ArcMap using Roads and Highways for Desktop and Event Editor doesn't change when conflict prevention is enabled. When an editor begins editing a route or event with conflict prevention enabled, a lock is acquired on that route or event. To acquire the lock, Roads and Highways first checks to make sure the edited version is reconciled with the lock root version. If a reconcile is required, you're alerted to first reconcile before proceeding with editing. If no reconcile is required, you're prompted to acquire the lock. There are options in Roads and Highways for Desktop and in Event Editor to configure the lock to be automatically acquired, so there is no prompt to acquire a lock for every route or event they edit.
In the scenarios above, enabling conflict prevention changes the editing workflow for the second editor, for example:
- Route edits and event edits—One route editor is going to make edits to route A in version A. Another event editor is going to make edits to event A on route A in version B. With conflict prevention, if the route editor acquires the lock first, they would be able to make their edits. If the event editor attempts to acquire an event lock for event A on route A, they would be informed route A is locked by the route editor in version A and would need to wait for the lock to be released to acquire it and make their event edits.
- Route edits—One route editor is going to make edits to route A in version A. Another route editor is going to make edits to route A in version B. With conflict prevention, the first route editor to acquire the lock is able to make edits to route A. If the second route editor attempts to acquire the route lock while the first route editor still has the lock, a message appears informing them that route A is locked by the other route editor in version A and they need to wait for the lock to be released to acquire it and make their edits.
- Event edits on the same event—One event editor is going to edit event A on route A in version A. Another event editor is going to edit event A on route A in version B. With conflict prevention, the first event editor to acquire a lock on event A on route A would be able to make edits. If the second event editor attempts to acquire the event lock on route A while the first editor still has the lock, the second editor is informed that event A on route A is locked in version A by the first editor. They need to wait for the lock to be released to acquire the lock and make the edits to event A on route A.
- Event edits on different events—One event editor is going to edit event A on a route A in version A. Another event editor is going to edit event B on route A in version B. With conflict prevention, the first event editor acquires a lock on event A on route A, while the second event editor acquires an event lock for event B on route A. Since the measures on the route don't change, each person can edit their event without impacting the other. While these event locks exist, no route editor can acquire a route lock to edit the route.
Once edits are complete, the lock should be released. To release a lock, the person who has acquired the lock must post their edits to the lock root version from the version where the lock was acquired. Once these changes are posted, the lock is released and anyone can acquire a route or event lock on the route for additional edits.
Desktop locking tools
Roads and Highways for Desktop has tools to view locks, acquire route locks, and release route locks. A locks viewer table can be opened in ArcMap from the Roads and Highways Editing toolbar. 
Conflict prevention is supported throughout Roads and Highways for Desktop. When enabled, you can expect to acquire route locks when performing the following editing activities and workflows:
- All Roads and Highways editing tools (Create, Extend, Retire, Realign, Reassign, and Reverse Route)
- Calibration point editing
- Generation of intersections
- Updating intersections
- Event registration
- Event editing
For route loading, generating and updating calibration points, removing duplicate centerlines, and other bulk operations performed against the entire network, you should coordinate with others to ensure all edits from child versions of the lock root are posted and no locks are present in the system before executing these processes. This will ensure the operations are run against the current version of the LRS Network.
Event Editor locking tools
The Event Editor also has tools to view locks, acquire event locks, and release event locks. A locks viewer table can be opened from the Versioning section of the Review tab on the Event Editor toolbar.
Conflict prevention is supported throughout Event Editor. When enabled, you can expect to acquire event locks when editing using the following widgets and tables:
- Add Point Events widget
- Add Linear Events widget
- Split Events widget
- Merge Events widget
- Event table
- Attribute set table
- Data Reviewer results table
REST locking tools
The Roads and Highways REST API provides REST endpoints to support conflict prevention and locking. Endpoints to determine if conflict prevention is enabled, query locks, acquire event locks, and release locks provide functionality for using conflict prevention when editing. Additionally, event editing APIs have been enhanced to support conflict prevention and enforce locking as well.
Conflict prevention administration
Enabling conflict prevention as part of everyday editing workflows will result in route and event locks being acquired and released as various edits are performed. If a situation arises where you've acquired locks and not posted edits in a timely manner, the need could arise for administration of the geodatabase to release the locks. To release route and event locks, the version the locks were acquired in must be deleted.
Once the version is deleted, the locks will be released automatically. Deleting the version before removing the locks ensures that any pending edits in the deleted version are not posted to the lock root version.
Although conflict prevention is not required when using Roads and Highways, enabling it prevents explicit and logical conflicts that could occur when editing in a multiuser geodatabase. These scenarios include the following:
- Two people editing the same route in different versions
- One person editing a route while someone else edits events on the same route in Event Editor
- Two people editing the same event on the same route in different versions
Disabling conflict prevention does not change the appearance or editing workflows in ArcMap using Roads and Highways for Desktop or in Event Editor. The only difference for editors when conflict prevention is disabled is that no messages related to locking and conflict prevention appear when performing editing workflows.