Multiple "Done" statuses vs "Resolution" best practices

[Benjamin Peikes]

Currently we lean towards having a single "Done" status, and using "Resolution" to specify the reason it's done. For example:
Resolution could be "Won't Do", but the status is "Done"
or
Resolution could be "Deployed", but the status is "Done"

Considering switching to using multiple "Done" statuses, like
"Deployed"
"Won't Do"
etc

I guess the question is why even have "Resolution", or are Resolutions really meant for Service Desk work items?

[Rohit Utukuri]

Hi @Benjamin Peikes

Jira uses resolution field value to determine if the issue/work item is resolved. Even if the status has been set to "Done" or "Won't Do" if the StatusCategory field is not set to "Done", Jira will still treat the issue as unresolved.  

For additional information review the link - https://support.atlassian.com/jira/kb/best-practices-on-using-the-resolution-field-in-jira-cloud/

[Trudy Claspill]

Hello @Rohit Utukuri 

Your answer is partially incorrect.

StatusCategory is separate from Resolution and does not determine whether or not Jira considers an issue "resolved".

StatusCategory is used to identify the Category to which a give Status value belongs. There are three StatusCategory values which are color coded as follows:

StatusCategory	Color
To Do	gray
In Progress	blue
Done	green

Each Status value belongs to one of the Status Categories.

Just as Status is not used by Jira to determine that an item is "resolved" so to StatusCategory is not used by Jira to determine that an item is "resolved". 

Perhaps your use of "StatusCategory" was a typo and you meant to say "Resolution", given that your first sentence was correct.

[Trudy Claspill]

Hello @Benjamin Peikes 

Did you find this KB from Atlassian?

https://support.atlassian.com/jira/kb/best-practices-on-using-the-resolution-field-in-jira-cloud/

And this video (not from Atlassian)?

Status vs Resolution in Jira – How to Set Resolution the Easy Way 

One reason to have and use the Resolution field is that Jira uses that field as the basis for the Created vs. Resolved reports. 

In the environments I have managed we have used "Closed" as the final status as a more generic term to indicate no additional work is being done without implying that any work was ever actually completed. We then use Resolution to indicate whether or not the work is Completed or interrupted/never done (Cancelled, Won't Do, Not Bug, Rejected).

We try to keep the number of Status values and the number of Resolution values low to reduce maintenance and complexity in reporting.

[Benjamin Peikes]

The problem with a single "Done" or "Closed" status, is that Automation rules dont work when there are multiple transitions that can take you to your "Done" or "Closed" status. Automation rules will:
* Pick an arbitrary transition as long as it goes from current status to the target status
* Ignore any restrictions on the transition

For instance, we have a transition called "Won't Do" that goes from any status to "Done". Currently this transition will bring up a "Won't Do" screen to take a comment so we can require one, and it automatically sets the Resolution to "Won't Do".

The issue is we have is regarding an automation we use. We have a status called "Work Completed", and we want to transition these issues to "Done" when they get deployed. We have an automation rule to do it, but because automation rules only can pick a destination Status, not a transaction, the automation rule can pick the "Won't Do" transition, which requires a screen and a comment. This makes the automation rule fail.

[Benjamin Peikes]

We do use the resolution field. That has it's own issues, namely that resolutions are global, which is completely ridiculous given service desk items, bugs and new features should have completely different resolutions.

It may be that you should never have a screen that allows a user to set a resolution, it should always be set by the transition.

[Trudy Claspill]

In the Transition Work Item action there is an options for selecting the specific transition you want to use.

[Trudy Claspill]

Regarding the global nature of Resolution values there are two ways to address that.

1. Use a third party app such as Extended Schemes that enables you to create Resolution Schemes to apply to projects/issue types.

2. Use workflow properties to limit the available Resolution values during a transition.

https://support.atlassian.com/jira-cloud-administration/docs/use-workflow-properties/#jira.field.resolution.include-and-jira.field.resolution.exclude