Hi everyone, our Jira workflow is getting more complicated as the team grows. We have several statuses, custom fields, and automation rules. What are some practical ways to keep Jira organized without making the workflow too difficult for users?
Hii Billy,
Keep only the statuses that users/business actually need.
Use conditions, validators and post functions wherever possible to control transitions, validate inputs and automate actions instead of adding more statuses and automations.
Avoid creating duplicate transitions where possible. If same transition is needed from multiple statues, use a single transition that can be triggered from both statuses rather than creating separate transitions.
For each change, review the existing workflow first and update the documentation accordingly. As the team grows and time passes, things become complicated.
Hello @Billy X
You can find what I say funny now, but the key is not always saying yes to any dubious request for a workflow change; evaluate what is needed and why, and see if there's another way to avoid bigger changes.
For me a workflow should describe the lifecycle of a ticket, not the whole business process.
Keep only the major stages, something like Open → To Analyze → In Progress → To Validate → Done
Everything else can be captured by a field, for example you could use Flag for blocked issue.
Hi.
One thing that is easy to overlook is documentation, especially when dealing with large workflows.
From my experience in a support role, I had to troubleshoot some very large and complex workflows. Even when documentation existed, it could still be difficult to understand how everything worked together.
What helped me a lot was going through the workflow from beginning to end and creating a functional diagram of it. I didn't just reproduce the workflow itself. For each transition, I documented things such as which role could execute it, what conditions or validators applied, and what the transition actually did. Some transitions also triggered additional actions, such as creating a Confluence page for example, so I included those as well.
This was particularly useful because you cannot always understand those details just by looking at the workflow diagram in Jira. You often have to open each transition and inspect its conditions, validators, post-functions, and other configuration.
Having all of that information in one diagram gave me a much clearer picture of how the workflow actually behaved, and it made troubleshooting and supporting it much easier.
So when a workflow is expected to grow because of business requirements or the process itself, I think documenting not just the workflow structure, but also its behaviour, can be extremely valuable.
All of the above is very sound advice, but it's qualitative. It describes what good looks like, not how to tell you've already drifted from it. What's missing is something to count.
At ServiceRocket, when we inventory an instance before a migration or cleanup, we count workflows, automation rules, filters, dashboards and custom fields, and then check how many of each are actually in use. The ratio of configured to active is the most telling number. On one estate we assessed, only 26 of 1,209 automation rules were enabled. Roughly 98% was dead weight that nobody had removed. Disabled-but-present config never appears in a workflow diagram. Yet whoever inherits the instance still has to read it, understand it, test it and carry it forward. That's a big part of why an instance feels harder to change than it looks.
You can run this inventory yourself. Do it on a schedule rather than waiting for a migration or licence review to force it, and cleanup becomes maintenance rather than a project.
We wrote up how an Australian energy leader tackled Jira sprawl while scaling from 2,000 to 6,000 users: https://www.servicerocket.com/resources/energy-leader-solves-jira-sprawl-with-an-atlassian-coe
Hi @Billy X,
Welcome to the Atlassian community!
I would measure before simplifying. Pull the Control Chart to find statuses items pass through in under an hour (those are not real states, just clicks), and check the automation audit log for rules that never fired in the last 90 days. That alone removes a lot of weight.
Then agree on one rule for new status requests: a status is justified only if ownership changes or if you need to measure how long work waits there. Everything else is a field or a label.
I would also watch out for workflow copies. Every project-specific workflow doubles your maintenance. Differences that are only about who may do what belong in conditions and permissions, not in a separate workflow.
Servus, Martin
I’d try to keep the core workflow as small as possible and use fields or labels for information that doesn’t actually change the state of the work.
For example:
To Do → In Progress → Review → Done
If every edge case becomes its own status, the workflow can quickly become difficult for the team to understand and maintain.
I’d also review which statuses are actually being used. If a status rarely contains work, or people regularly disagree about when to move an issue there, that’s usually a sign that it can be simplified.
For automation, I’d start with repetitive actions that remove manual work rather than adding more workflow states.
The goal for me would be: when someone opens the board, they should immediately understand where the work is and what needs to happen next.
It looks like you're new here. Sign in or register to get started.
