Jira Workflow Design: When to Use a Status vs. a Custom Field
- onpoint ltd
- Aug 3
- 7 min read
A team builds their first Jira Service Management project. Six months in, they've got 40 custom fields, three of them named some variation of "Status," and a workflow with 14 statuses because someone kept adding a new one every time a ticket didn't fit the existing options.
Both problems come from the same root mistake: not knowing which one, status or custom field, was supposed to hold which piece of information in the first place.
This is the decision matrix that settles it, plus the one field almost every guide forgets exists.
Quick answer
Use a status when the value represents a stage every ticket must physically pass through, the kind of thing that gates what happens next and drives your board columns.
Use a custom field when the value is a classification, a category, or a data point that doesn't stop or start anything on its own, impact, affected system, customer tier, department.
Use the resolution field when you need to record why a ticket ended, set once, at close, separate from which Done-style status it landed on.
If you're still not sure, ask one question: does changing this value need to trigger a workflow transition (notify someone, unlock a new set of actions, move the board card)? If yes, it's a status. If it's just information sitting on the ticket, it's a custom field.
What a status field actually controls in a service desk workflow
A status is a stop on the workflow. It's tied to transitions (the arrows connecting one status to the next), it drives which board column a ticket sits in, and it belongs to a status category, To Do, In Progress, or Done, that Jira uses for reporting rollups and sprint health gadgets.
Statuses gate behavior. Move a request to "Waiting for Customer" and the SLA clock can pause automatically. Move it to "Resolved" and a resolution screen can appear, demanding an answer before the transition completes. That gating is the entire point of a status. If a value on your ticket isn't gating anything, it's probably not a status, it's a custom field wearing a status's clothes.
What a custom field actually controls, and why it never gates movement
A custom field captures data a system field doesn't cover. Impact, urgency, affected component, customer account tier, none of these represent where a ticket physically sits in its lifecycle. They're attributes of the ticket, not stages of it.
The distinction matters because Jira treats them completely differently under the hood. System fields, including status, come built into every instance and can't be renamed or removed. Custom fields are yours to define: the type, the options, who can see or edit them, and whether they show up on the customer-facing portal at all. A select list custom field forces one clean answer per ticket, which is exactly why it's the right type for anything you plan to filter or report on later.
One naming rule worth following from the start: don't give a custom field the same name as a system field. Two fields both called "Status" in the same instance turns every filter and every report into a guessing game about which one someone meant.
The Resolution Field
Status and resolution get confused constantly, and it's an easy mix-up because they often change at the same moment. A Done-category status just means the ticket no longer needs active work. It says nothing about why. The resolution field is what carries the why, fixed, won't fix, duplicate, cannot reproduce, and it comes with its own timestamp separate from the status transition itself.
Skip the resolution field and you'll have a pile of "Closed" tickets with zero way to tell how many were actually fixed versus abandoned, duplicated, or never reproducible. That's a reporting gap that only shows up months later, when someone asks "what percentage of our tickets are genuine fixes" and the honest answer is "we can't tell."
Jira status fields vs custom fields: the decision matrix
Your situation | Use this | Why |
The value represents a stage every ticket passes through | Status | Drives the board, gates transitions, ties to SLA pause/resume logic |
The value is a classification that doesn't stop or start anything (impact, urgency, category) | Custom field | Pure data, filterable and reportable, doesn't need to gate movement |
You need to record why a ticket reached Done, separately from which Done status it hit | Resolution field | Purpose-built for this, carries its own timestamp |
Agents need one internal status name but customers need a friendlier one | Status, with the customer-facing name overridden | JSM lets you set a different display name per audience on the same status |
You need one reporting value across multiple projects that each use different per-project statuses | Custom field, mirrored via automation on every transition | Gives you a single, consistent field for cross-project dashboards without forcing every project onto one workflow |
You want to track how long a ticket sat with a specific team or department, and that team isn't reflected in your status names | Custom field, tracked with SLA calendar logic keyed to the field's value | Lets you measure time-in-value against something the workflow itself doesn't represent as a stage |
You're tempted to add a new status because the current ones almost describe the situation | Custom field, almost always | If it doesn't need to gate a transition, it doesn't need to be a status |
When a status needs to say one thing to agents and another to customers
This is a JSM-specific capability most Jira Software guides never mention, because it doesn't exist outside service desk projects. In a request type's workflow settings, you can set a customer-facing display name for a status that's different from what agents see internally. Your team might track a ticket as "Escalated to Tier 2," while the customer portal simply shows "In Progress," because the internal escalation detail isn't something a customer needs, or should, see.
This is the right tool when the temptation is to build a second, customer-safe copy of your workflow. You don't need two workflows. You need one status with two names.
When to track SLA time against something that isn't the ticket's actual status
Most SLA setups measure time against status: the clock runs while a ticket is "Open," pauses on "Waiting for Customer." But some teams need to measure time spent with a specific team or department, and that department isn't a workflow stage, it's a custom field value that changes while the ticket's status stays exactly the same.
The pattern: build a custom field for the department or team currently holding the ticket, then configure SLA time tracking keyed to changes in that field's value instead of (or alongside) the status. Each time the field's value changes, that becomes its own countable time window, giving you a report of exactly how many hours each team held the ticket, independent of whatever status it happened to be sitting in.
When one custom field beats fifty inconsistent statuses across projects
If your service desk runs multiple projects, each with its own workflow because different teams need different steps, cross-project reporting on status alone becomes close to useless. Project A's "In Progress" and Project B's "Being Worked" mean the same thing but don't roll up together cleanly.
The fix: add a single, read-only custom field, call it something generic like "Global Stage," and use an automation rule to set its value every time any ticket transitions, regardless of which project-specific status triggered it. Each project keeps its own tailored workflow. Your dashboards get one clean field to report against across all of them.
Not sure which of your current Jira fields should actually be statuses, or which statuses should be fields?We can review your workflow and identify where your service desk is getting overcomplicated—so you can simplify reporting, clean up SLAs, and make your queues easier to manage. Book a Jira workflow review.
Common mistakes in Jira Workflow Design
Creating a new status for every edge case.
If a value doesn't need to gate a transition, it's a custom field. A workflow with 12 or more statuses is usually a sign several of them should have been field values instead.
Two fields with overlapping names.
A custom field named "Status" sitting next to the system Status field guarantees confusion in every filter and every JQL query written by someone new to the instance.
Treating resolution and status as the same thing.
They answer different questions. Status answers "is this still being worked." Resolution answers "why did it stop."
Building a second workflow just for customer-facing wording.
JSM already lets you rename what customers see per status. Reach for that before duplicating an entire workflow.
FAQ
What's the actual difference between a Jira status and a custom field?
A status represents a stage in the workflow and gates what happens next, transitions, notifications, SLA pauses. A custom field holds a data point or classification that doesn't gate anything on its own. If changing the value needs to trigger a workflow action, it belongs as a status. If it's just information sitting on the ticket, it's a custom field.
Is the resolution field the same as status?
No. Status shows whether a ticket is still active. Resolution records why it stopped being active, fixed, won't fix, duplicate, and carries its own separate timestamp. Many Done-category statuses look interchangeable until you need to report on how many tickets were genuinely fixed versus abandoned, and that's exactly what resolution is for.
Can a Jira status show a different name to customers than to agents?
Yes, in Jira Service Management specifically. Each request type's workflow settings let you set a customer-facing display name for any status, separate from the internal name agents see. This avoids building two parallel workflows just to hide internal detail from customers.
Should I use a custom field or a status to track which team owns a ticket?
A custom field, in almost every case. Team or department ownership is a classification, not a workflow stage, unless ownership genuinely changes what actions are available on the ticket. If you need to measure time spent with each team, SLA time tracking can be configured against the custom field's value directly.
How do I report consistently across projects that each have different statuses? Add one read-only custom field and use an automation rule to set its value on every transition, regardless of which project-specific status triggered it. Each project keeps its own workflow. Reporting gets one consistent field to run against.
Further reading
Not sure which of your current fields should have been statuses, or the other way around? Get in touch.
Comments