Practical Workaround for Jira Cloud: Re-empty the Resolution Field - News, tips & guidance for agile, development, Atlassian-Software (JIRA, Confluence, Bitbucket, ...) and Google Cloud

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.