You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
Before we get started: I advocate to design the Jira User experience as simple as possible. Thus, if you do not necessarily need to differentiate resolutions, I would suggest to generally set them via workflow transition post functions. However, if you have important use cases for different resolutions, this article discusses how to configure Jira and Jira Align accordingly!
Many organizations use resolutions in Jira to capture and display what happens at the end of a lifecycle of work items and drive analytics from that data. With the way Jira and Jira Align integrate, it is possible to keep working with different resolutions in Jira, but some things need to be considered with regard to the integration.
For general advice on integration, please refer to the Jira Align help.
Those materials also describe the behaviours of the integration regarding the resolution of an issue:
Additionally, the the following aspects in mind need to be kept in mind:
Now, let's look at the synchronised work items individually.
Many of the organizations using Jira Align use Jira for managing and analysing the work on the individual team level - an integration which would not support all transitions of stories through Jira Align would be acceptable for a lot of them.
In this case, the only aspect to be considered is the fact that there will be two statuses in Jira which display that the work item is at the end of its lifecycle. A status being mapped to “Canceled” will illustrate that the work item has stopped being relevant and another status will indicate that the work has been successfully completed, for example a state called “Accepted”.
For example for the “Canceled” resolution, only resolutions like “ Canceled, Duplicate, Obsolete” would make sense.
The restriction of resolutions during a workflow transition can be achieved by transition properties.
Picture: workflow transition properties help configuring resolutions depending on the transition target status
Features are owned by the team of teams/program/ART. Jira Align offers a wide range of capabilities to manage the work on the program level, analyse it and provide reports on it. This means both that the use cases for the usage of resolutions in Jira gets less important and that Jira Align becomes the tool in which feature work items are mostly or even entirely managed. The ability to transition features without any restrictions becomes very important.
Henceforth we advise that resolutions are set automatically by workflow transition post functions for features. However, if desired, the solution described for stories can be applied for features as well if the positive and negative implications are considered well and the decision is made to (temporarily) maintain extended use cases for resolutions in Jira.
If you would like to use multiple resolutions in a Jira workflow while integrating with Jira Align, please have a look at the article by @Sam Tsubota "Jira and Jira Align Integration: Syncing a Jira Date Custom Field with Jira Align Accepted Date". He describes how to map the "Accepted Date" to a custom field and integrate this custom field into a Jira workflow for a seamless user experience. Stories could then transition to the “Accepted”-State in Jira Align independent from a resolution.