All Collections
Change governance
General
Stories
Conflict Flagging on User Stories
Conflict Flagging on User Stories

Spot and flag conflict in user stories before any work takes place

Olamide Olaifa avatar
Written by Olamide Olaifa
Updated over a week ago

You can use Elements to discover conflict in planned changes or work already in progress before any merge conflict happens.

Article Outline

  • Prerequisites

  • The logic of Conflict Management

  • How conflict flagging works

  • Resolving Conflicts in Stories

  • You might be also interested in

Prerequisites

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.

You might be also interested in

  • User stories - to be able to get the right solution, you really have to start from defining the problem by getting into the shoes of who is going to face the issue

  • Custom grid views - you can create custom view of all stories that are currently in conflict

  • Business requirements - business requirements are a tool for documenting your business needs for driving higher value in your company

  • Managing process change with requirements and stories - you can easily raise requirements and stories from the diagram activities. You can also see the status of requirement and story implementation for each activity

  • Sharing requirements and stories - in order to share a requirement or a user story with other users and collaborate on it, you need to copy a unique URL from the Share tab

Did this answer your question?