How to Find and Remove Unused Jira Automation Rules

Clones, abandoned experiments, rules (flows) switched off years ago. Nobody deletes any of it, because nobody can prove a rule is safe to delete.

A Jira site does not accumulate a thousand automation rules (Jira now calls them flows) on purpose. It accumulates them one reasonable decision at a time: a rule gets cloned so it can be adapted for another project, an experiment gets switched off instead of deleted, a migration leaves both the old and the new version behind, and the person who would know which is which has moved on.

On one real Jira Cloud site there are 1,214 rules across 98 projects. 884 are switched on; 330 are off. The 330 have been off for an unknown length of time, and nobody deletes them, because deleting requires certainty that nobody has.

Why "disabled" is not "safe to delete"

A disabled rule costs nothing to run. Under step-based billing from December 2026 it is still free — the billing is for steps that execute, and a switched-off rule executes nothing.

So the cost of the 330 is not money. It is that they are indistinguishable from the live ones when you are looking for something. Every search returns them, every audit has to account for them, every new admin reads them trying to understand the system, and the rule that should have been deleted two years ago looks exactly like the rule that is switched off for a quarter because of an ongoing migration.

Why nobody deletes

Three honest reasons, none of them laziness:

  • You cannot tell what depended on it. A rule that is off might still be referenced by a chain someone will re-enable. Jira shows no relationships between rules, so "does anything point at this" has no answer inside the product. That question is the subject of what breaks if I switch this rule off.
  • You cannot tell what it did. The name is Copy of copy of SLA v2 and the logic is a tree of branches. Reading it takes minutes, and there are hundreds of them.
  • You cannot tell whether it is a duplicate. Two rules with different names can do the same thing; two rules with the same name can differ in one condition that matters.

What actually helps

Not a delete button — a way to answer the three questions above quickly enough that a decision becomes cheap.

Read the rule in one screen. Automation Map renders each rule as a tree rather than as JSON: trigger, conditions, branches, actions, with smart values resolved to the fields they touch. Reading a rule takes seconds instead of minutes.

See what points at it. Every rule carries its incoming and outgoing links — which rules can trigger it, which rules its actions wake — including the links that are blocked because the receiving rule has Allow flow trigger switched off. The map draws chains only between enabled rules; for a disabled rule it shows web requests to other rules, work items it creates in other spaces, and its "Copy of" pedigree.

Find the copies. Rules named "Copy of …" are linked to the rule they were copied from, so a clone family shows up together — comparing what they do is still yours.

Ask instead of browsing. The Rovo agent searches the rules by trigger and action and points out likely overlaps, with links to the map and to each rule in Jira — a shortlist to check.

Know where usage lives. Whether a rule still runs is in Jira's Performance insights (execution count per flow); Automation Map reads configuration only. What it flags from the configuration: throwaway rules left enabled (test, temp, tmp, del or "copy of" in the name), enabled rules not changed in over two years, rules missing the site's name prefix, and "Copy of" clones — on each rule in every edition, and together on the Audit page with CSV on Advanced and Enterprise.

A "Copy of" rule still switched on, linked by a dotted clone line to its switched-off original, with the findings "looks like a test/temporary/clone rule but is ENABLED" and "no NAMESPACE: prefix"

A copy left running while the original is off — the kind of rule this article is about

A cleanup that finishes

  1. Start with the throwaway rules the app flags. Test, temp and "copy of" in the name, still enabled, and enabled rules nobody has changed in two years — check each against Performance insights, and the ones with no executions go first.
  2. Then the copies the map links as "Copy of" another. Compare each with its original on the rule card and keep one.
  3. Then rules that look alike. Search by trigger or action, or ask the Rovo agent, and let a person decide.
  4. Leave the rest alone. A rule that is off and still listened for is someone's paused migration — check what its trigger listens for against what enabled rules write; "who touches this field" and the Rovo agent do that search. It belongs on a list, not in the bin.

NOTE: The app never deletes or edits anything. It never changes anything in Jira; every change is made by you, in Jira, with the finding open next to it.

FAQ

How do I find unused Jira automation rules (flows)?

Whether a rule still runs is in Jira's Performance insights. From the configuration, Automation Map flags throwaway rules left enabled, enabled rules unchanged for two years, rules without the site's name prefix, and "Copy of" clones — the shortlist to check against those counts.

Do disabled automation rules cost money under step billing?

No. Billing counts steps that execute, and a disabled rule executes nothing. The cost of keeping them is confusion, not money.

How can I tell whether two rules are duplicates?

Start with the name: "Copy of …" rules are linked to their original on the map. For the rest, search by trigger or action — two rules with different names can do the same thing, and two with the same name can differ in one condition — and compare them on the rule card.

Is it safe to delete a rule that has been off for a year?

Only once you know nothing waits for it. The map draws chains only between enabled rules, so "no links" on a disabled rule proves nothing; check what its trigger listens for against what enabled rules write, then decide.

Does the app delete rules for me?

No. It never changes anything in Jira. It tells you which rules are candidates and why; the deletion is yours to make in Jira.

How long does it take to map a site of a thousand rules?

A minute or two, from the export file. The reading and deciding is the part that takes time, which is why the tree view and the clone links matter more than the speed.

Make deleting cheap again

Nobody needs a thousand rules. They need to be able to prove which ones they do not need.

👉 Automation Map for Jira — see every rule, live and dormant