Diesen Artikel auf Deutsch lesen
Practical workaround for Jira Cloud: Empty the Resolution field again
Flexibility through customizable workflows
Every task has a life cycle. A Product owner or project manager creates the task, employee A processes the task and hands it over to colleague B for quality assurance, who checks the work and closes the ticket. A task is created, it goes through a few (or a lot of) intermediate stages, and at some point, it is completed.
These task cycles are mapped in Jira in the form of workflows - and workflows are one of Jira's great strengths. Each team or project can set up and use its unique, specific processes for handling tasks. This makes Jira very flexible and suitable for a wide variety of use cases.
Resolution: End of the task life cycle
In this context, the resolution field in Jira is an important feature because it specifies the reason for which a process was closed. At the same time, it eliminates the need to maintain multiple fields, indexing why the task is closed. Resolution thus captures important information from the team while reducing the time spent managing workflows.
Jira assumes that the lifecycle of a task is over, and it is done when the Resolution field has a value. This field is where Jira stores how an issue was resolved, such as whether the task was completed or canceled.
Resolution in "Team-managed Projects”
Jira Cloud has offered a feature called "Team-managed Projects" for some time. These projects are designed to allow each team member within the specific project to manage the team's work and processes without having to ask admins for help.
However, Atlassian no longer works with the Resolution field in so-called "Team managed Projects" but instead uses the "Status Category" fields, which is roughly equivalent to Resolution, and "Status Category Changed Date" (instead of "resolution date" or "resolved").
What if the team still wants to work with the Resolution field in these projects? Then an automation rule is needed to set the resolution to a specific status when it transitions. So far, so good.
Reopened operations and the resolution field
Now, in certain scenarios that are not so far-fetched, it happens that a Resolution that has been set once is to be set to zero again. A task is transitioned to the final status (e.g. "Done"), and the Resolution field is set to a certain value according to the workflow. But then the team discovers that work is still required on the task. Or, as is often the case, the ticket was just inadvertently moved to final status.
In most cases, the workflow should allow the issue to be transferred back to a previous status. But in Jira Cloud, the problem is that this operation does not automatically zero out the set resolution. As a result, the ticket is back in process, but the resolution has a value, so Jira assumes the task is done.
This can have broad implications. For example, because the resolution contains a value, the ticket shows up in reports and evaluations as completed, even though it is in progress (again).
Challenge for admins
In order for the Resolution to be automatically removed when the final status is changed to a previous status, an extensive manual change to the existing workflow is required - or too many workflows, if you want to avoid the problem above from occurring across projects and globally.
In this case, the admin team would have to add a so-called post function to each transition across workflows so that the Resolution is emptied when a task is reopened. Understandably, administrators would like to avoid such an effort.
Can that not be done via Jira automation as well? Automation can be used to edit the Resolution value ("Edit Issue Fields") but not to clean up the field again.
A solution from the community
Nevertheless, there is a straightforward way, as a member of the Atlassian community has shown! You see, the problem can actually be corrected with an Automation rule. The workaround uses the "Edit Field" action and then the "Advanced Options".
Here is a screenshot from user Yaron showing the elegant solution:
This workaround saves admins a lot of effort in customizing workflows in their Jira Cloud instances and helps to get even more out of Jira automation.
And the example nicely illustrates the value of an active, knowledgeable user community like the Atlassian community: it often provides practical solution ideas and workarounds that help immediately, even with demanding administrative challenges.
Want to learn more about the automation capabilities in Jira? Want to get more out of your Jira system and learn ways to make administration more efficient?
Our experienced Atlassian professionals are happy to support your team with a Consulting Package Plus. We also offer a dedicated module training on Automation in Jira that will help you get more out of Jira - and even reduce administrative overhead in the process.
- Manage Your Jira Data Center Instance Wisely With Guardrails
- Awesome Custom Fields: An Important Jira Feature Has Become More Accessible and Understandable
- 5 Reasons Why ITSM Teams Rely on Jira Service Management Data Center
- Integrating Confluence into Jira Service Management: How ITSM Teams Efficiently Handle Service Desk Requests