You can use Elements to discover conflict in planned changes or work already in progress before any merge conflict happens.
Registered and verified Elements account
Your Space needs to be on Enterprise plan
The Logic of Conflict Management
When a user decides to modify a certain piece of Salesforce metadata, they do not know who, when, or how someone else is going to modify the same metadata in another Salesforce environment. This might result in one work overwriting another in production and someone's effort and the fruits of their labor being lost. If a sophisticated DevOps tool is used, a merge conflict will be detected but will require potentially significant and time-consuming reworks.
How conflict flagging works
Clients may have teams that use different ticketing systems to manage their work and do not use the same deployment tools to manage their releases to Salesforce production org. This prevents the visibility of how various modifications may interact or be in conflict with one another.
Conflicts usually arise when different stories might impact the same set of metadata in different ways. In Elements, whenever an open story touches metadata that is linked to another open story, both stories will automatically be flagged as having conflicts.
In the 'conflict' tab on a story, in the right panel, users can inspect all potential conflicts. Each conflict record lists both the story and the metadata that are the source of the overlap.
Resolving Conflicts in Stories
User with requirement manager permission can resolve the conflict by opening the record and changing the status to 'resolved'. They can add a comment as well to explain how the resolution will work.
Resolving conflict may require that the stories should be implemented sequentially. The nature of the change may mean that despite touching the same metadata there is no actual conflict to worry about.
As soon as all conflict records are marked as 'Resolved' on a story, the story's overall conflict status changes from 'Open' to 'Resolved' as well.