Instant workflows health check with two simple JQLs

Tomáš Vrabec_mlkuef

Many of us are facing to wrongly created workflows, creating a mess in Jira. There are inexperienced admins or event the managers creating workflows with no, or very limited knowledge about rules and must-haves within Jira and workflows logic.

Status is not Resolution!

In small instances, it's kind of easy to analyze those and fix them.

But what to do in the large instances?

And how to watch the instance in the future?

Today, I will share my experience with inconsistencies in Statuses vs Resolutions. 

Basic queries for checking instance health

Basically, there are two states of inconsistency which could occur. Issue is in status category Done (Green), but Resolution is Empty OR Issue is in status category To Do (Grey) or In Progress (Blue), but Resolution is set. 

This would let not only to user confusion, but also to wrong interpretation by Jira. See both examples below.

1. Done, but not Done

statusCategory = Done AND resolution is EMPTY

Can cause:

• Wrong interpretation by Jira boards
• Wrong calculation of statistics in Sprints or any Agile reports
  • User suppose that issue is Done, but JIRA thinks it is Open
• Wrong representation of Issue in Confluence (Issue is not marked as strike-through and issue is not calculated as Resolved)
• Issues could appear in the filters (and boards) even when they are Done (But not Resolved)

    2. Open, but not open

statusCategory != Done AND resolution is not EMPTY

Can cause:

• Wrong interpretation by Jira boards
• Issues are not present on System filter (For example "Open issues on Dashboard")
• Wrong calculation of statistics in Sprints or any Agile reports
  • User suppose that issue is Open or In Progress, but Jira thinks it is Done
• Wrong representation of Issue in Confluence (Issue is marked as strike-through and issue is calculated as Resolved)
• Issues could disappear from the filters (and boards) even when they are Open or In progress (But Resolution is not set and some of filters goes with "Resolution is Empty" part)

Always zero!

So, here is the way, how to simple check your workflows health. Just run those two JQL. There should be always ZERO results. 

My best practice is also to save those two JQL as the filters and subscribe to those two filters on daily basis. This would let to an email notification, if some wrong workflow would appear in the system. Then I can go, fix it and let the inexperience admins know, why and how build the workflows correctly.

Handling Resolutions should be always:

1. Set when moving to status category Done
   1. Automatically
   2. By forcing the user to choose Resolution in transition screen
2. Removed by automated post-function when issue is leaving status category Done (Reopen etc)
3. Self-transition "Change Resolution" is appropriate only with Workflow Condition "Only in status category Done"

If you are looking for scripted condition to check the status category, here is how to get status category name: 

issue.getStatus().getStatusCategory().getName()

And you have to compare it with status category names, which are:

• "New" (Grey statuses)
• "In Progress" (Blue statuses)
• "Complete" (Green statuses)

All of the above are from my point of view very fundamental Jira basic configurations, which have to be followed to have the application behaving as expected.

More details, officially from Atlassian, even with step-by-step instructions how to fix those, could be found at https://confluence.atlassian.com/cloudkb/best-practices-on-using-the-resolution-field-968660796.html

Dave Mathijs

Absolutely fundamental, a must-read and apply. Thanks @Tomáš Vrabec for the reminder.