Schemes, workflows and filters

Delete schemes nothing uses, consolidate identical ones, find bad practice in workflows, and clean up saved filters.

If the word scheme is unfamiliar, read the Jira words page. In short: a scheme is a bundle of configuration that projects share, and instances tend to accumulate hundreds of them.

Unused Schemes Cleanup

What it does. The name undersells it. It finds 16 kinds of unused configuration object, not only schemes: also the workflows, statuses, screens, field configurations, work types, priorities and resolutions that sit inside them. You pick one type at a time, scan, and it reports how many exist, how many are in use and how many are unused. Then you select rows and delete.

Admin Toolkit → Unused Schemes CleanupIllustration

Unused Schemes Cleanup

Scan for Unused Schemes

Pick one object type at a time. The selector is grouped by area.

Workflows

Workflow SchemesWorkflowsStatuses

Screens

Work Type Screen SchemesScreen SchemesScreens

Fields

Field Config SchemesField Configurations

Work Types

Work Type SchemesWork Types

Priority

Priority SchemesPriorities

Resolutions

Security & Permissions

Issue Security SchemesPermission Schemes

Notifications

Notification Schemes

Workflow Schemes — schemes not assigned to any project

212

Total

147

In Use

Unused

	Name	Description
	CRM: Software Simplified Workflow Scheme	Created for a project archived in 2023
	Copy of ITSM Workflow Scheme	—
	OPS: Incident Workflow Scheme	In use by Operations

Delete selected (2)Show DetailsStart Over

The type selector is grouped, so you can work down a whole area — for example clear unused workflow schemes, then the workflows nothing references, then the statuses no workflow uses.

Group	Type	What “unused” means for it
Workflows	Workflow Schemes	Not assigned to any project.
Workflows	Workflows	Not in any workflow scheme.
Workflows	Statuses	Not used in any workflow.
Screens	Work Type Screen Schemes	Not assigned to any project.
Screens	Screen Schemes	Not used in any work type screen scheme.
Screens	Screens	Not in any screen scheme or workflow.
Fields	Field Config Schemes	Not assigned to any project.
Fields	Field Configurations	Not used in any field config scheme.
Work Types	Work Type Schemes	Not associated with any project.
Work Types	Work Types	Not in any work type scheme.
Priority	Priority Schemes	Not assigned to any project.
Priority	Priorities	Not used by any issue.
Resolutions	Resolutions	Not used by any issue.
Security & Permissions	Issue Security Schemes	Not assigned to any project.
Security & Permissions	Permission Schemes	Not assigned to any project.
Notifications	Notification Schemes	Not assigned to any project.

Clean from the outside in

Delete unused schemes first, then re-scan the objects inside them. A workflow that looked used five minutes ago becomes unused the moment the scheme referencing it is gone, so the second pass always finds more than the first.

Priorities and resolutions are judged by usage, not by reference

“Not used by any issue” means no issue currently has that value. That is a good reason to remove it from the dropdown, but check first whether a filter, dashboard or automation rule names it — those are not part of the check.

Start with anything called “Copy of…”

Copies made during a change and never removed are the bulk of the sprawl. They are unused, unreferenced and unambiguous. Clear those before you consider anything that looks deliberate.

Scheme Deduplication

What it does. Finds schemes that are in use but identical to another scheme. It groups them, shows which projects use each one, and reports totals for schemes scanned, duplicate groups found and schemes inside those groups.

It compares eleven kinds of object: Issue Type, Workflow, Workflow Scheme, Screen, Screen Scheme, Issue Type Screen Scheme, Field Configuration, Field Configuration Scheme, Permission, Notification and Priority schemes.

Why bother. Ten identical schemes means ten places to make the same change, and nine chances to forget one.

It reports; it does not consolidate for you

There is no button here that repoints a project or deletes a scheme. You get the groups, the projects using each one, and a CSV export — the change itself is made in Jira, deliberately, because deciding which of two identical schemes survives is not a decision an app should make. Once you have repointed the projects the duplicates become unused, and Unused Schemes Cleanup can delete them.

Two settings decide how strict identical is. For workflows, you choose whether conditions, validators, post-functions and properties have to match as well as the transitions. For screens, whether the tabs have to match or only the set of fields. Loosen them and you find more groups that are harder to justify merging; tighten them and you find fewer, which you can act on with more confidence.

Team-managed projects are excluded, and that is not an oversight: a team-managed project keeps private copies of its own configuration, so its schemes are duplicates by design and cannot be consolidated. If the scan could not read everything within its budget it says This scan did not read everything, rather than presenting a partial sweep as a complete one.

This is the tool to run before Unused Schemes Cleanup

Deduplication points projects at one shared scheme, which turns the duplicates into unused schemes. Then the cleanup tool can delete them. Doing it the other way round leaves the duplicates in place, because they were all in use.

Identical today is not identical forever

Two teams may deliberately keep separate schemes so they can diverge later. Ask the project owners before consolidating a scheme that is actually in use.

Workflow Health

What it does. Reads your company-managed workflows and reports the three kinds of bad practice that make a workflow expensive to live with. It changes nothing.

Check	What it finds	Why it matters
Oversized workflows	More statuses or transitions than the limits you set — 15 and 30 by default, adjustable from 5 to 40 and 5 to 80.	A workflow nobody can hold in their head is a workflow nobody will maintain correctly.
Broken reachability	Orphaned statuses with no transition leading into them, and statuses that cannot be reached from the initial status at all.	An issue can never arrive there, so the status is a lie in every report that counts it.
Wrong status categories	Final statuses that are not in Done, and initial statuses that are not in To Do.	An issue that ends outside Done never counts as completed — not on a board, not in a burndown, not in any `statusCategory` query.

Before it scans you choose whether to cover all workflows or only active ones, and set the two size limits. Results are searchable, filterable by finding type, show which projects use each workflow, and export as CSV. A workflow list that stopped before the end is reported as This scan did not read everything, not as a clean bill of health.

Scan the active workflows first

An unreachable status in a workflow no project uses is a curiosity. The same finding in a workflow behind four hundred issues is a reporting bug somebody is already living with.

Filter Management

What it does. Lists saved filters with their owner, their sharing scope and their JQL, and lets you act in bulk. Search By Name, By Owner, By Project or By JQL — that last one finds every filter whose query mentions a given string — and narrow by sharing scope: All, Private, Project, Group or Global.

Why it matters. Saved filters are the configuration nobody audits, and the most common way Jira data ends up shared more widely than anyone intended.

Admin Toolkit → Filter ManagementIllustration

Filter Management

Audit saved filters, review sharing permissions and take bulk actions.

By NameBy OwnerBy ProjectBy JQL

Enter filter name (substring match)...

All

1,204

Total Filters

218

Unique Owners

Shared globally

Filter Name	Owner	Sharing	JQL
All open incidents	Marina Rocha	Global	`project = OPS AND resolution = Unresolved`
Board — team alpha	(deactivated user)	Group	`project = ALPHA ORDER BY Rank`
My tickets	João Lima	Private	`assignee = currentUser()`

Bulk actions — 2 filters selected

Reassign OwnerMake PrivateRemove Global ShareReplace in JQLExport CSV

It cannot see other people's private filters, and it says so

Jira's API only exposes filters that are shared or that you own, so a private filter belonging to somebody else cannot be listed — by this app or any other. The tool states that above the results rather than presenting the list as complete. Read the audit as covering shared filters plus your own.

Action	What it does	Use it for
Reassign Owner	Moves ownership to another person.	Filters owned by deactivated users. These are what break dashboards and boards when an account goes away.
Make Private	Removes all sharing from the selected filters.	Filters that were shared by accident.
Remove Global Share	Removes only the global scope, leaving other sharing intact.	Reducing exposure without breaking a team's access.
Replace in JQL	Find-and-replace inside the JQL of the selected filters. Before you commit, it says how many filters would change and validates each result, naming any that would become invalid JQL — those are left untouched.	A project key that changed, a renamed custom field, a status that no longer exists. This is the alternative to opening two hundred filters by hand.
Export CSV	Exports the current list, up to 20,000 rows.	Evidence for an audit, and a before/after record.

Two searches worth running today

Filters shared globally, and filters owned by deactivated users. The first is an information-exposure question. The second is a list of dashboards and boards that are already broken or about to break.