Are Your Jira Statuses Breaking Your Reports? Here is How to Fix Them

[#1]

Every Jira admin has seen it: a simple workflow that somehow turns into a mess. Tickets get stuck, dashboards show the wrong numbers, and velocity drops. Usually, the real problem is a mix-up with Jira’s basic building blocks: statuses, status categories, and resolutions. Let's break down how to fix your workflow so it actually helps your team. 

Status vs. Status Category: What's the Difference?

A Status is a custom step you make (like "Awaiting QA"). A Status Category is Jira’s built-in label: To Do, In Progress, or Done. That tells the system how to treat that step. You can build as many custom statuses as you want, but every single one must map to one of these three categories.

Jira uses colors to show them: gray for To Do, blue for In Progress, and green for Done. Why does this matter? Native filters and Jira Query Language (JQL) look at the category, not your custom statuses. If you map a status incorrectly, like putting a completed "Canceled" status into the gray To Do category, your backlog numbers will be wrong, and your boards will break. 

Company-Managed vs. Team-Managed Workflows

Before adding statuses, you need to check your workspace type. In Company-managed projects, admins set global rules. If you change a workflow here, it instantly updates every single project sharing it. This is great for strict company-wide reporting.

In Team-managed projects, anyone on the team can tweak their own board without waiting for an admin. Those local changes won't break the rest of the company, making it perfect for teams that need to move fast. 

How to Manage Custom Statuses Safely

The biggest mistake you can make is creating too many statuses. A hyper-specific status for every tiny task slows teams down and makes reporting a nightmare. Keep it simple and reuse existing statuses if they fit.
If you are managing global updates in company-managed projects, remember that changing a status name updates it everywhere instantly. Jira doesn't warn users, so always tell your team first. If you need to delete a status, do it safely:

Make sure the workflow is inactive first.

Move all existing tickets into a valid, active status. If you don't, you will lose data and break your past reports.

Let your team know where their active tickets went. 

The Secret to Good Reports: The Resolution Field

The number one reporting issue in Jira involves the resolution field. Jira only considers a ticket fully closed when the resolution field is filled out, no matter what column it is in. If a ticket moves to Done but the resolution is empty, it will stay in your open issue filters forever. Fix this using one of two ways: 

Automatic (Post Function) 

If tickets should just be marked "Done" automatically:

• Edit your transition to the Done status.
• Go to Post Functions and click Add post function.
• Choose Update issue field, select the resolution field, and set your value.
• Publish the workflow. 

Manual (Transition Screen)

If users need to choose why a ticket is closing (like "Fixed" or "Duplicate"):

• Create a screen with only the resolution field.
• Map this screen to the transition leading to Done.
• This forces users to pick a reason before they can close the ticket.

Another important tip: don’t forget reopened tickets. If a ticket moves from Done back to an active status, you must add a Clear Field Value post-function to that transition. If you don't, the ticket stays crossed out and looks closed. Also, never create a custom resolution named "Unresolved"; Jira reads empty fields as unresolved automatically, so typing that word will actually break your reports. 

Tracking Your Clean Workflow 

Once you fix your categories and clean up your resolution fields, your workflow is finally ready to scale. The next logical step is seeing exactly how fast work moves through that new pipeline. But as your projects grow, finding out where tickets get stuck can be tough without building complex JQL queries or making messy changes to your setup.

This is where an app like Timepiece - Time in Status for Jira fits in perfectly. Instead of manually calculating cycle times, Timepiece does the heavy lifting. It measures exactly how long a ticket sits in a specific status or custom field (like a specific sprint or block reason).

It even has a built-in AI Assistant, so you can skip the complex configurations and just ask for the report you need in plain English or any other languages. 

By combining a clean, disciplined workflow with the right reporting tool, you keep work moving and your team happy. Want to see where your tickets are spending the most time? Explore Timepiece - Time in Status for Jira on the Atlassian Marketplace.