Browse around in the Atlassian Community and you’ll find a lot of people puzzling about the difference between “closed” and “resolved”. The confusion is understandable. Why would you close an issue unless you thought it was resolved? And if an issue is resolved, why would you leave it open?
The simple answer is that this all comes down to Jira’s flexibility. You can use the Closed and Resolved Jira workflow statuses however you want - we’ll discuss that below. Note, however that reaching a Resolved or Closed (or Completed, or Done, etc.) status, is different from setting an issue’s resolution field.
Closed and Resolved Statuses in a Jira Workflow
You get to decide how you name, and where you place, statuses in your workflow. (Remember that statuses are global so changing the name of an existing status is not recommended.) Status names should be short and should tell you the current state of an issue. The final status of your workflow could have any number of names (fixed, done, etc.), but for now let’s just look at Closed and Resolved.
You get to interpret (and then communicate to your users) what the words Closed and Resolved mean. In many workflows, one person/team will “resolve” an issue - meaning that once they believe they have fixed the problem, they transition the issue to a the Resolved status. Another person/team may then be responsible for testing the solution. If it passes, the issue can then be Closed.
Or you could say that an issue is not Closed until it’s been through a retrospective. Or you could build two possible end points to your workflow, using Resolved for those issues that actually get resolved and Closed for the issues that you decide not to fix. How you use these terms is completely up to you. If you find that it’s not helpful to have both a Resolved and a Closed status in your workflow, you can remove one.
Jira Resolution Field
So why do those issues in the Done (or the Resolved) status still show up as unresolved?
Regardless of whether or not you have a Jira workflow status called “Resolved,” you still need to set the Resolution field. (Avoiding using “Resolved” as a status might help reduce confusion.) The Resolution field is a text field which is intended to tell you why the issue was closed.
Maybe in a perfect world, every issue would only be reported once, every issue would be worthy of being fixed, and every issue could be fixed. We don’t live in that world. That’s why there’s a Resolution field. It means you can have you workflow come to one nice, tidy ending point, but still be able to sort out the issues that were successfully fixed from the ones that weren’t fixed, but were still closed.
You can set and order resolution values in your project. Common resolutions include:
- Won’t do
- Cannot reproduce
- Known error
- Hardware failure
- Software failure
You can also create your own resolution values. Resolution values may be designed for specific teams or projects (for instance, Marketing may have a value of “Published” ). Note, that you are strongly advised to avoid creating values such as “None” or “Unresolved”. The resolution state of Jira issues is “unresolved” by default and creating a resolution option of “unresolved” or “none” will cause confusion. The fact that a user is setting a resolution value should mean that, one way or another, the issue is resolved.
If you’re confident that issues that make it to the end of your Jira workflow will have been resolved in the most desirable way - DONE, you can set a post function to set the resolution once an issue has transitioned to the final status in your workflow. However, many experts recommend creating a transition screen that prompts the user to set the resolution. This ensures that the actual reason for closing the issue gets recorded - which is the purpose of having the Resolution field.