Available with Standard or Advanced license.
Conflicts can be discovered when the named version is reconciled with the default version. If conflicts are detected during the reconcile process, they are initially resolved in favor of the edit version and can be reviewed in the Conflicts view.
Conflicts occur in the following instances:
- The same feature updates in both the current edit version and the target version
- The same feature updates in one version and is deleted in the other
- A topologically related feature or relationship class is modified in the current edit version and the target version
The Conflicts view contains all the conflict classes and their features or rows in conflict. In branch versioning, conflicts are persisted in a system-owned GDB_CONFLICTS table. This allows you to review conflicts one at a time or, if necessary, you can manage conflicts over multiple edit sessions, review and resolve conflicts, and leave and come back later to continue making changes using the Conflicts view.
The Conflicts view allows you to do the following:
- Determine the fields or rows in conflict
- View conflicts
- Mark conflicts as reviewed or not reviewed
- Resolve conflicts by designating the representation to use to replace features or attributes
Caution:
If managing conflicts over multiple edit sessions, any unreviewed conflicts are cleared when a second reconcile operation or post operation are performed. This process deletes the history of conflict resolutions.
Once you finish reconciling and reviewing conflicts, you can complete the merging process by posting changes to the target version.
Open the Conflicts view
Follow these steps to open the Conflicts view:
- In the Contents pane, click the List By Data Source button
. - Ensure that you are connected to a named version. To change versions, right-click the web feature layer data source
and click Change Version 
. - Click the Versioning tab.
- Complete one of the following options to open the Conflicts view:
- Click the Reconcile button
and complete the reconcile process.
If conflicts are discovered during the reconcile, a prompt will appear, asking if you want to review conflicts. Clicking Yes will open the Conflicts view.
- To further review and manage conflicts after a reconcile has been completed, click the Conflict Manager button
on the Versioning tab.
- Click the Reconcile button
The Conflicts view can be docked anywhere in the app or positioned as a floating window. This allows you to interact with a map view at the same time to provide context and further explore the data.
Use the Conflicts view
The Conflicts view contains all the conflict classes and their features or rows in conflict. Conflicts are organized using the data source, class, conflict category, and ObjectID. Workspaces for all maps in the project are listed in the Conflicts view. The conflict classes represent the web feature layers in conflict for the entire service.
The Conflicts view consists of three main sections for working with conflicts. The Conflicts list contains all conflict classes and features in conflict. The information grid shows the attributes and values for all representations of the feature in conflict selected from the Conflicts list. The Conflict Display viewer is used to view and compare the different representations for geometry edits in a map.
Reference the image and table below to review the elements of the Conflicts view:
| Element | Description |
|---|---|
1 | Conflicts list—The conflicts list section contains all conflict classes and features in conflict. |
2 | Information grid—The information grid section shows the attributes and values for all representations of the feature in conflict. |
3 | Conflict Display viewer—The conflict display viewer is an expandable section located at the bottom of the Conflicts view. This allows you to view the conflicts as they appear on the map, as well as navigate and identify features in the display. |
4 | Filter Reviewed Conflicts—Checking this box at the top of the conflict list filters the list to show only conflicts that have not been reviewed. |
5 | Red indicator—A red indicator to the left of the row identifies a conflict. For example, if the feature's geometry was edited in each version, a red indicator appears next to the Shape field. |
6 | Show All |
7 | Show Conflicts |
8 | Show credits for service layers—Clicking this icon brings up a dialog box listing the providers and makers of the basemap. |
9 | Conflict Display navigation tools—The following tools allow you to navigate and control the version displayed and navigate within the conflict display windows:
|
—Applies a fixed zoom in on the map.
—Applies a fixed zoom out on the map.
—Zoom the map to center on the selected object.
—The selected object will briefly flash blue and change
to red in the Conflict Display viewer.Conflicts list
All conflict classes and features are shown in the conflicts list on the upper left side of the Conflicts view. This list shows the total number of conflicts for web feature layers for the entire service.
Click an object drop-down arrow 
to see the conflicts for each feature. These are separated into the following categories:
- Update-Delete—The feature was updated in the current version and deleted in the target version.
- Delete-Update—The feature was deleted in the current version and updated in the target version.
- Update-Update—The feature was updated in both the current and target versions.
When you select an individual feature's ObjectID in the conflict list, the fields and attributes in the Current, Target, and Common Ancestor versions of the feature appear in the information grid on the right side of the Conflicts view.
Tip:
Conflicts that have not been reviewed are shown in bold. Conflicts that have been reviewed are no longer bold.
Information grid
In the information grid, you can view the different representations of attribute values for a selected feature. Having the attributes and values for all representations of a feature in conflict allows you to see how the attribute values differ across versions and helps you determine the representation of the data to preserve. All fields are displayed in the information grid and a red indicator appears to the left of the row for attributes that are in conflict.
The following columns display attribute values for different representations of the feature:
- Current—Represents the current state of the features and attributes in the named version. This includes any edits that you made.
- Target—Represents the features and its attributes in the default version.
- Common ancestor—Represents the features and attributes when the version was initially created or at the time of the last reconcile operation.
If a feature has been deleted in either version, <Deleted> appears for that version's attribute value. If features have been inserted into a named version and they are promoted to a conflict, Did not exist appears for the Target and Common Ancestor columns.
Tip:
All fields are displayed in the information grid within the Conflicts view, however, fields with a field-level conflict filter applied are not identified as in conflict and do not display a red indicator.
Conflict Display
The Conflict Display button opens the conflict display viewer section at the bottom of the Conflicts view. The conflict display viewer allows you to view conflicts as they appear on the map, as well as navigate and identify features in the display. The conflicts displayed are based on the individual feature's ObjectID selected in the conflict list.
The conflict display navigation tools are located below the Conflict Display viewer. These tools contain two drop-down menus that allow you to change the versions being compared, where the version options include the Current, Target, or Common Ancestor version.
The content in the conflict display differs depending on whether the conflict class is present in the active map:
- When the conflict class is in the active map, the conflict display shows all map layers, uses the map symbology, and includes the basemap.
- When the conflict class is not in the active map, the conflict display only shows the layer in conflict, uses the default symbology, and does not include the basemap.
Mark conflicts as reviewed or not reviewed
Once you determine the fields or rows in conflict, you can mark a feature as reviewed. You can keep track of the features in the list you have reviewed because those marked as reviewed no longer appear in bold.
To come back to a feature conflict later, right-click the ObjectID in the conflicts list and click Mark as not reviewed. This causes the feature to appear in bold again.
If you check the Filter Reviewed Conflicts check box at the top of the view, you can filter the list to show only conflicts that have not been reviewed.
With branch versioning, you can also add a review note. Right-click a feature, click Add Review Note, and type text in the Add Review Note text box. To edit an existing review note, right-click a feature and click Edit Review Note.
Note:
Review notes are cleared on the next reconcile and post operation.
Resolve conflicts
When you resolve conflicts, you are deciding which representation of the features and attributes you want to keep. After the reconcile operation, you can use the Conflicts view to specify the representation to keep. Keep in mind that using the replacement options in the Conflicts view is the same as performing an edit operation.
From the Conflicts view, right-click a version, dataset, feature, or attribute and select one of the following replacement options:
- Replace With Current Version
- Replace With Target Version
- Replace With Common Ancestor Version
The following are different levels in which you can use the replacement options to resolve conflicts:
- Attribute replacement
This occurs at the field level. If there are conflicts in attributes, you can replace only the attribute value in the current version with one from either the current, target, or common ancestor representation. To do so, right-click the attribute in conflict and click the option on the menu.
- Feature replacement
This occurs at the row level. You can replace an entire feature with the representation of the feature in the current, target, or common ancestor version. This means the fields in conflict are replaced.
- Class-level replacement
You can replace the current representation of the entire feature class with the current, target, or common ancestor version representation to resolve the conflict. This replaces all the conflicting features and attributes at once, allowing you to quickly update and replace conflicting features. If there are multiple features in the Conflicts list, all of them are replaced with the version you choose.
To choose a class-level replacement option, right-click the feature class name in the Conflicts list and click the version you want to use.
- Complete replacement
This occurs at the root level. This option replaces all conflicting features and feature classes in the list with the representation designated. If you have multiple feature classes and objects in conflict, all of them are replaced with the version you choose.
Right-click the version and connection information at the top of the Conflicts list and click the version you want to use to replace all conflicts.
Field-level conflict filtering
In some cases, you may want edits that were applied to a field or set of fields to remain when conflicts are detected during reconciliation. The following are examples of when you may want to filter out conflicts detected on a field when reconciling:
- A batch update is performed on a field in different versions.
- Information is written to a field based on the edits performed in the version.
To prevent conflicts from being identified when the same attribute is updated in the parent and child versions, you can use the Add Field Conflict Filter tool to define the set of fields to filter from conflicts. A field conflict filter allows you to tag a field or set of fields in a feature class to filter them from conflict detection. Conflicts will not be returned during the reconcile operation if only fields with conflict filters are edited. This is only applicable when you are defining conflicts by attribute.
You can use the ListFieldConflictFilters Python function to identify when a feature class or table has conflict filters defined.
Note:
All fields are displayed in the Conflicts view; however, fields with a conflict filter applied are not identified as in conflict and do not display a red indicator.
Branch versioned data is always reconciled with conflicts in favor of the edit version; fields with a conflict filter contain the value from the edit version.
You can use the Remove Field Conflict Filter tool to remove these conflict filters from the fields.
Note:
Services with branch versioned data must be restarted to pick up changes from the Add Field Conflict Filter or Remove Field Conflict Filter tools.
Resolve conflicts with attribute rules
Attribute rules improve the editing experience and data integrity for geodatabase datasets. When performing a reconcile in which conflicts are defined by attribute (column), immediate calculation or constraint rules are evaluated for features that have been updated in both the DEFAULT version and the version being reconciled. If a constraint rule is violated during this process, the merge will not occur, the feature will be promoted to an Update-Update conflict and can be reviewed in the Conflicts view.
Resolve conflicts with relationship classes
Relationship classes can be used to help enforce referential integrity between related objects. If branch versioned data sources participate in a relationship class, the reconcile process evaluates this data for referential integrity. If referential integrity is violated, participating features are reported as conflicts and can be reviewed in the Conflicts view.
Deleting a feature from an origin relationship class may trigger a message to delete a feature from the destination relationship class. Therefore, be aware of the ramifications of simply replacing conflicts involving feature classes that participate in relationship classes.
The following is an example of a conflict that can arise between relationship classes:
- In a parent version, you add a destination feature and relate it to a feature in the origin class.
- In a child version, you delete the same origin feature that was used to relate the new destination feature.
- When the edits are reconciled, an update-update conflict is detected on the destination class while a delete-update conflict is detected on the origin class.
Another example is the following:
- In your electric utilities feature dataset, you delete a pole that has a relationship to a transformer, causing the related transformer to also be deleted.
- In another edit session occurring at the same time, an editor alters the attributes of the transformer you had just caused to be deleted by deleting its related pole.
- When the edits are reconciled, an update-delete conflict is detected on the origin and destination classes.
In this last example, if the second editor chose to replace all conflicts with the edit session representations, the pole and transformer deleted during your edit session will be re-created.