A Jira workflow audit you can act on.

Start with the question you need answered

A structural workflow audit asks whether work has a valid route from creation to completion. It is useful after changing statuses or transitions, when taking ownership of an unfamiliar Jira site, and during a recurring configuration review.

Before you start, record the site, workflows in scope, reviewer, and review date. Identify which statuses are intended to be final. A status name alone is insufficient: Jira groups statuses into To do, In progress, and Done categories.

You can follow the checklist manually in Jira. Workflow Linter automates structural checks across the workflow definitions it retrieves and produces findings with evidence and suggested remediation.

Six checks for a workflow review

1. Can work enter the workflow?

Find the initial transition and its destination. Confirm that the destination exists and is the intended starting status. Investigate missing targets and unexpected additional entry paths.

2. Can every intended status be reached?

Trace directed transitions from the starting status. An isolated status may be left over from a redesign, but review its purpose before removing it. Include global transitions when checking reachability.

3. Can work leave each active status?

A reachable status outside the Done category with no outgoing route is a dead end. Confirm the intended next step with the workflow owner before adding a transition.

4. Can active work eventually reach Done?

A status can have outgoing transitions and still be trapped in a loop. Follow the complete path to a Done-category status. A connected diagram does not necessarily provide a completion route.

5. Are broad transitions intentional?

A global transition provides a route from every status to one destination. Inspect its restrictions and validation rules in Jira. Missing validator metadata is a reason to review the configuration, not proof that an approval can be bypassed.

6. Can another administrator understand the design?

Review deprecated statuses, identical transition names leading to different destinations, and unusually complex graphs. These may be valid choices. Record the reason for keeping them so future reviewers do not repeat the same investigation.

One broken path can explain several findings

Consider this synthetic example: creation leads to To Do, then to In Progress. A Done status exists, but no transition reaches it.

• Done is unreachable from the initial path.
• In Progress is a non-Done dead end.
• Neither To Do nor In Progress has a path to Done.

These findings share a possible root cause. If the intended process permits it, adding the missing In Progress → Done transition can resolve all four findings. Review the business rules before changing the workflow.

See the tested before-and-after example. It uses synthetic data, not a customer result.

Evaluate Workflow Linter on one authorized site

1. Open Workflow Linter on Atlassian Marketplace. Review compatibility, permissions, price, and trial terms before installing on a Jira Cloud site you administer.
2. In Jira settings, choose Marketplace apps, then Workflow Linter. If a development copy is also installed, select the entry without the DEV label.
3. Choose Run first scan. Check the scan timestamp and any coverage or storage-limit warnings.
4. Review the highest-severity finding against the workflow in Jira. Decide whether it identifies a real defect, an intentional design, or a question for the workflow owner.
5. Use View CSV export or View JSON export to inspect the report. Keep any evidence you need within your own approved systems.

Judge the evaluation by whether the report identifies a useful action or provides a clear structural baseline. A score of 100 means no active findings under the current checks; it does not certify the workflow or prove every user can complete every transition.

Try Workflow Linter on Marketplace

Marketplace displays the applicable site-tier pricing and evaluation terms before purchase.

Use the report in a client handoff

For Jira consultants, a structural report can support discovery, a workflow redesign review, or a maintenance checklist. Pair it with your review of permissions, transition rules, automations, and business requirements.

For each confirmed finding, add an owner and a planned action to the client's own work tracker. After an authorized fix, scan again and compare the result with the evidence you retained. Workflow Linter stores the latest bounded report; it does not maintain a complete audit history.

Interested in evaluating the app for your practice? Contact Workflow Linter with your use case and the type of explanation your team needs. No client access or exports are needed to discuss fit.

What a structural audit cannot establish

Jira conditions, permissions, validators, and transition actions can affect behavior even when the graph has a path to completion. Workflow Linter does not execute those rules, inspect issue content, repair workflows, certify compliance, or identify every reason an individual work item is stuck.

The app reads workflow configuration through Atlassian Forge and declares no external network egress. Review the security model and scan and storage limits when deciding whether it fits your review.

Related Atlassian documentation

• Workflow statuses, categories, and directed transitions
• Conditions, validators, and global transitions

Published by Workflow Linter, the maker of Workflow Linter for Jira. Updated September 4, 2026.