Configscope

Jira workflow limit per scheme checker

List your workflow schemes and workflows below to see which one hits the September 2026 caps first. Everything runs in your browser — nothing is sent anywhere.

Workflow schemes

One row per workflow scheme. Count every workflow assigned to it, including ones shared with other schemes — the cap is 150 workflows in a single scheme.

+ Add scheme

Workflows

One row per workflow. Count the statuses that appear in it — the cap is 200 statuses in a single workflow. Your site-wide status list can be much longer than that; it is not what gets checked here.

+ Add workflow

Where you stand

Sorted by how close each container is to its cap. Whatever is at the top will hit the wall first.

Why "per site" is the wrong question

Workflows are capped per scheme, not per instance. This is the most common thing admins get wrong when they hear "workflow limit" for the first time. Four hundred workflows spread across your Jira site is completely fine. A hundred and fifty-one workflows attached to one scheme is not — and the total-workflows number that shows up in admin exports never tells you that on its own.

Statuses are capped per workflow, not globally. Same shape of mistake in the other direction. Your organization-wide status list can run into the thousands with no consequence. What matters is how many distinct statuses appear inside any single workflow's diagram. A workflow that has quietly absorbed years of "just add one more status" requests is the one to check first.

When these limits apply

September 2026 — not yet in force. The 150-workflows-per-scheme and 200-statuses-per-workflow caps checked on this page take effect then, along with priorities and components per space, field options per field, releases, permission grants and work item security levels.

March 2026 is a different limit. Custom fields and work types per space were already capped starting in March 2026. If you are only over on fields, that deadline has already passed — this page is not about that one.

Always confirm current values against Atlassian's data limits and guardrails documentation — Atlassian revises them.

If a container is going to hit the wall

1. Split the scheme. Move a coherent subset of projects — a business unit, a product line — onto a second workflow scheme. This is the direct fix for a scheme over the workflow cap, and it is usually less disruptive than it sounds if the projects already differ in process.
2. Move rare transitions into a separate workflow. If a workflow is over on statuses because of an edge case used by one team a few times a year, pull that branch into its own workflow rather than carrying it inside the main one every project uses.
3. Merge near-duplicate statuses. "In Review", "In QA Review" and "Pending Review" are usually the same status with three names. Consolidating these both frees headroom under the per-workflow cap and makes the board easier to read.