Jira Image of the Day: When to Set a Workflow Resolution

[#1]

Concept Relates To

Application Type	Jira (Jira Work Management and Jira Software), Jira Service Management, Jira Core
Deployment Type	Jira Cloud, Jira Data Center

What is shown?

A sample workflow to illustrate where to place the most important part: a resolution. Be sure to set a resolution when an item is resolved and clear the resolution if an item moves backwards in the workflow.

Visit: Admin > Work items > Workflows (Cloud)
Visit: Admin > Issues > Workflows (Data Center)

What can we learn?

In the example workflow, decide where you consider an item resolved. I generally see resolutions set in one of two places.

One common place is after the main work is complete and is awaiting validation.

Another option is when an item reaches its final status. Where to do it is up to you; just make sure it occurs.

My Preference

Since this issue has a testing step, I’ll choose to set the resolution in the “Start Testing” transition. That way, the development team can use the resolution to communicate how much testing is needed to the QA team.

If the developer selects a resolution of “Duplicate” or “Won’t Do”, then the tester just needs to confirm that they agree and close the issue. If the developer selects a resolution of “Done”, the tester knows they need to run their full testing plan.

---

Back to intro and image list

[Stephen_Lugton]

Hi @Rachel Wright ,

Thanks for the article.

A lot of what I'm currently doing is incident management, service requests, etc., and in that context resolution is only set when the incident or whatever we're dealing with has been fully resolved, which takes it out of the JSM unresolved queues.

I don't think I would ever have a case where we set the resolution until all the work was Done ("Done"), or rejected ("Won't do" or "Duplicate").

In your case, you're setting the resolution early before testing, we had a workflow step to add a comment when a work item transitions to 'In testing', and auto assigned the work item to the tester, which gave the tester any additional info needed.  Or at least we did until we were finally able to fire the tester for gross incompetence (unfortunately his father in law was the CTO so we couldn't fire the tester, but then the CTO was "invited to leave" when we discovered fraudulent activity, so we were then able to fire the tester)

[James Rickards _SN_]

Thanks for the write up on one of the most forgotten field within in Jira.

I'm not sure I am in agreement with the tip to set resolution early, but whatever works for your team is what is important for you.

After 20 years of Jira and many different workflows, I've found it best to align the resolution to a "green" status. That's what Jira expects, and it ensures that the OOTB reports are consistent with each other. Jira seems to drive some reports from the status category, and some from the Resolution field.

For Company Managed projects, I always automatically set resolution during transition and never show it to users.  It is very rare that the value placed in the field is actually used to inform operational or strategic decisions, and making a user choose a value just increases their cognitive load. If a distinction is required such as "Won't Do" & "Released", I use a different terminating status, as it is much more intuitive to filter on status for most users.

Team managed projects seem to have just done away with the field, and you need to set it via automations to get some of the OOTB Dashboard Gadgets (e.g. created vs resolved) to work as expected.