Skip to main content

How to Find Unused Workflows, Schemes and Custom Fields in Jira

· 7 min read
NGPilot
Quick Answer

On Premium and Enterprise, open Settings → System → Site optimizer. On Free and Standard that panel does not exist, and — less usefully than you might expect — Atlassian's free CLI doesn't cover workflows either, so the honest answer for lower tiers is the per-scheme optimizer (available on all four plans) plus manual checks. Whatever route you take, remove a custom field from its screen first and the instance last.

Jira configuration does not rot the way Confluence content does — nobody notices a redundant workflow scheme on a page. It shows up as slowness. Atlassian's own cleanup guidance notes that too many custom fields can clutter an instance and affect its performance, and that every field is evaluated during create, update and index operations.

The hunt is the easy part, once you know which tool applies to you. The awkward part is that Atlassian gates its site-wide cleanup tooling to the top two plans — and the free fallback doesn't fully cover the gap.

What you'll learn
  1. What Site optimizer covers, and the plan it needs
  2. What Atlassian's free CLI actually does and doesn't cover
  3. How Atlassian defines an "unused" field — the five conditions
  4. Why an archived project still pins a scheme
  5. The removal order that keeps you able to undo it

Option 1: Site optimizer (Premium and Enterprise)​

Settings → System → Site optimizer

Atlassian's documentation describes it as a central hub for monitoring and improving the health of your Jira data, with actions covering issue archival, custom-field cleanup and removal of unused project role permissions. The structure splits into Limits (forward-looking — how close you are to a threshold) and Guardrails (the cleanup actions themselves).

For custom fields specifically, the field optimization guide is the one to read. In Limits → Fields per space → Review you get:

  • Spaces approaching or exceeding the field limit
  • Unused custom fields that may be suitable for cleanup
  • How field usage has changed over time

For each unused field it shows the type, contexts, screens, last-used date and a recommendation, and offers to move it to trash — recoverable for a limited period before it becomes permanent.

The Limits view is the part people miss. It reports how close you are to a threshold before you hit it, which is worth checking quarterly whether or not you think you have a problem.

Plan requirement

Atlassian is explicit: the Site optimizer is available only on Jira Premium and Enterprise plans and requires Jira administrator permissions. On Free and Standard it is not in your admin panel.

Option 2: what the Atlassian CLI actually covers (and doesn't)​

The Atlassian CLI (ACLI) is Atlassian's own free tool for Jira Cloud, available on Windows, Linux and macOS and on all Jira Cloud plans. It's genuinely useful — but set your expectations correctly for this particular job.

Its modern command structure is acli <product> <feature> <action>, for example acli jira workitem search or acli jira project list. You may find older examples online using an --action flag style, for instance acli --action getWorkflowList. That syntax belongs to the previous generation of the tool and does not work with the current one.

And for configuration cleanup specifically, the gaps are decisive:

  • There is no acli jira workflow command. Workflows, workflow schemes, statuses and transitions are not covered by the CLI.
  • acli jira field handles field definitions only — create, update, delete, cancel-delete. There is no list subcommand, so it cannot enumerate your custom fields for you either.

One practical warning if you script around it: check that a subcommand actually exists before relying on it. Run acli jira --help and read the output rather than trusting that a command ran without complaint.

caution

If you specifically need to enumerate unused workflows from the command line, the REST API is the more reliable path. Do not assume the CLI covers it.

Option 3: the per-scheme optimizer (all plans)​

This is the option most people miss, and it changes the picture for lower tiers. Optimize field configuration schemes is documented as available on Free, Standard, Premium and Enterprise:

Settings → Work items → Field configuration schemes → Optimize scheme

It scopes the analysis to one scheme rather than the whole site, and gives Atlassian's explicit definition of an unused field. The tool reports which fields can be reduced; you can then remove them from the scheme, create an optimized variant for a selected space without changing the original, or delete a scheme that is no longer associated to any spaces.

Atlassian defines unused as all of these being true:

  1. Haven't been used on a work item in the last two years
  2. Aren't associated to a screen or scheme
  3. Were made by a Jira administrator — not created or used by Jira, a plugin, or a Connect or Forge app
  4. Aren't used in workflows
  5. Aren't used in Forms

The third condition is the counter-intuitive one: the field must have been made by a human admin. It excludes system fields created by Jira itself or by an app, which are not yours to delete.

Option 4: manual checks​

When none of the above fits, these need no tooling at all:

Workflows. Go to Settings → System → Workflows. Look for workflows whose only associated scheme belongs to a project that no longer exists. Atlassian's own advanced cleanup guidance recommends verifying that no validator or post-function on a workflow depends on a custom field before deleting it.

Fields. Settings → Work items → Fields lists every custom field. The ones worth auditing are those nobody can name a use case for — cross-check each against whether it appears on a screen, in a workflow, or has a value on any work item.

Screens and screen schemes. These accumulate silently, and Atlassian's cleanup guidance calls out screens with no scheme, no workflow and no populated tab as candidates for removal.

The rule that catches people: archived is not gone​

An archived project still references its schemes. A workflow whose only scheme is attached to an archived project still has a live referrer, and deleting the workflow will break transitions on anything you restore later.

This is why "no scheme references it" is necessary but not sufficient. Before deleting, check whether the scheme is attached to an archived project, and if so whether that project is genuinely finished or merely dormant.

Remove in this order​

Atlassian's guidance on custom fields is a ladder, and the order matters because the rungs are not equally reversible:

  1. Remove from the screen. It stops appearing on create, view and edit. Values on existing work items are untouched. Fully reversible.
  2. Remove from the scheme. Narrower, still reversible.
  3. Remove from the instance. Only now consider it. This is where data becomes hard to recover, and Atlassian explicitly warns against treating a database query as proof — confirm in the UI that the field has no data before you get here.

Sources​

Related guides