Best Practices for Setting ‘Resolution’ field

[#1]

The first rule of a Jira admin should be “We do not create a Resolution with the name Unresolved or None”

The second rule of a Jira admin should be “We do not create a Resolution with the name Unresolved or None”

The third rule is…. Aah.. you get the point!

Platform	Cloud
Type of project	Company Managed Projects (CPM)
User role	Jira Admin

Show me one Jira admin who didn’t struggle with Resolution field when talking to teams/clients, and I’ll show you a happy man/woman! Jokes aside, the Resolution field is one of the most important fields in Jira for many reasons. The main use, in my humble opinion, is that Jira considers that the lifecycle of an issue has come to an end, if and only if (⟺ iff) the issue has a resolution. We will come back to this shortly.

Resolution's main use

In addition, the second best reason is to avoid having multiple final statuses which indicate that no more work has to be done for these issues. Imaging if you had the following workflow on the left, or even “better” if you had also “re-open” transitions from each of the final (green) statuses (image on the right):

Things would be even more complicated if you had more of “In progress” statuses which had transitions to all the final statuses. If that would seem confusing to you, try to imaging how the end user would feel if they would see a bunch of final statuses to choose from. Imaging try to explain a complex workflow with many business requirements, while having to deal with all these final statuses! This would be very complicated and cumbersome task.

For the above reasons, in Jira the resolution field comes to take the place of multiple final statuses and instead of having any of the above workflows, we can simply have the following:

And when the issue transitions to Done, then the user can choose a resolution from the available that we (the Jira admin) will create

An issue with a resolution will look like the following picture, where you can see its resolution next to the status name:

Resolution's connection to Jira's Functionalities

As we said, the main reason of why the resolution field is important, is because this field sets the “flag” of when an issue came to and end. It is the simple source of truth for Jira to know when that issue is really done and no further work is needed.

There are many native functionalities in Jira that depend on the "Resolution" field. Some of them are (and they are not restricted to):

• Issues having its key strikethrough on boards

• Reports about issues (for example, "Created vs resolved")

• System filters (for example, "Open Issues")

• Events (when issue is resolved)

• Notifications (when issue is resolved or closed)

Worst Case Scenario

Imagine now you are a Jira admin and your boss asks you to add two values to your resolution field: Unresolved and None. So you do that, because well…. he’s your boss (not your leader). Now let’s say the same boss asks from you to create a dashboard with all created vs resolved issues. So you do and then your boss comes and say to you that the results are not correct. To be more precise on the 30th of December, 27 new issues were created but only 9 were resolved!

So you take a look at the gadget above and you think that something’s wrong here:

• Either Jira has a bug or

• Something is wrong with the configuration of this instance

So you go ahead and google real quick the jira.atlassian.com for any open bug, but alas you can’t find anything. You decide to dig a bit deeper and see what’s wrong. You quickly navigate to advanced issue search and writing the following JQL project = ssp ORDER BY resolution ASC, you get the below results:

Well?

Can you see spot the problem? At a first and quick glance, a young Jira padawan wouldn’t be able to see the problem, but he/she could clearly count that only 9 issues has a resolution! Just like your boss said. The rest of them are all unresolved.. or are they?

Taking a closer look at the resolution column we see that the word Unresolved is written with two different formats: With normal letter (box A) and with italics (box B).

And suddenly everything falls into place! That new “Unresolved” resolution you had entered a few days ago, managed to mess up your results and confuse you and your boss as well. If you were to count the “Done” resolution issues, along with those of the “normal” Unresolved resolution, then you would get (you guessed it) a total of 15 resolved issues. Which is the number that Jira yield on that dashboard gadget.

Conclusion

So we are coming back to the first two rules of this article and the moral of the above story:

⚠️ We do not create a Resolution with the name Unresolved or None

Any issue that has the Resolution field set is treated by Jira applications as "resolved". The Issue Navigator displays "Unresolved" when no resolution is set for an issue. So adding a resolution named Unresolved/None and setting it in an issue will mean that the issue is seen as resolved.

Best Practices

Some best practices to prevent your issues from having a mistakenly set resolution, or/and the appropriate one are:

1. Create a post function on the transition that leads to the "Done" status to set the resolution as something fixed: By doing to you are setting an appropriate and acceptable resolution.

2. Create a screen with the resolution field on it, then map this screen to the transition to the "Done" status: By doing so, you are making the resolution field available to the users who are transitioning the issue to Done

3. Use the workflow properties to include/exclude the resolution you want, depending on the final status (if you happen to have more that one)

4. In addition to (2) it’s a good practice to add a validator and to make the resolution field required: By doing so you are making certain that when the issue transitions to Done, and the transition screen appears, then the user will not forget to choose a resolution from the drop down menu.

5. If you happen to have a reopening transition or a status that allows it to be reached from any other status, you'll need to create a post-function to clear the value of the "Resolution" field. I can’t stress this enough but this is a rule which you shouldn’t forget and most likely tattoo it on you.

[Summer Hogan]

This is great information @Alex Koxaras _Relational_ - thanks for sharing! 

[Paul Heath Armengol]

Hi Alex @Alex Koxaras _Relational_ 

How do you set workflow properties to include/exclude certain resolutions depending on the final status?

Also, are the workflow properties and their values documented anywhere?

TIA

[Alex Koxaras _Relational_]

HI @Paul Heath Armengol 

You can exclude/include resolutions by using the workflow properties found here: https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/

In your case you would need to enter jira.field.resolution.include or jira.field.resolution.exclude as a property and as a value the resolutions' IDs.

[Darrel Jackson]

This article needs an update as you can no longer get the sprint ID by hovering over the ... menu in the sprint board.

[Belto]

Hi @Darrel Jackson , I verified on a test site and I see that hovering over the ••• still provides the URL with sprintId at the bottom of the page. Could it be possible that you were looking at a team-managed Board?

This method is only applicable to company-managed Boards.

[Darrel Jackson]

I have verified his in our Jira Cloud Premium instance on a company-managed project. This is using the early access program for enhanced board and backlog.

https://community.atlassian.com/t5/Jira-Software-articles/Welcome-to-the-Early-Access-Program-for-Jira-s-enhanced-board/ba-p/2364509#M1276

It no longer shows the sprint ID on hover.

If I disable the enhanced board and backlog view then I do see the sprint ID.

[Belto]

Thank you for confirming. Indeed this method does not apply for the new enhanced board experience. I've sent this feedback to our product team to make sure they take this into consideration.

[Rich Johnson]

Great write up! One correction though as I had to go searching for this...

Correction - Under best practices, Step 4 - This is not possible. You cannot add a validator on the resolution field. See this thread for details.

[Aurelien Petit]

Here is an alternative method to view the ID of a sprint:

1. Navigate to 'Issues'.
2. Click on 'More', then select the 'Sprint' field.
3. In the dropdown list, select the sprint for which you want to know the ID.
4. Change the issue query from 'Basic' to 'JQL'.
5. The sprint name will be converted to the sprint ID in the JQL query.

It is also a good way to see if some tasks have been allocated to the wrong sprint, which could have been filtered out in the board's 'Backlog' tab.