nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How are Jira admins deciding which old automation rules are safe to keep vs remove?

Yusuf Khawaldeh

Hi everyone,

I’m trying to understand how people handle automation cleanup once a Jira instance has been around for a while.

The hard part doesn’t seem to be creating new rules. It’s figuring out:

- what rules still matter
- who owns them
- where duplicate or overlapping rules exist
- what is actually safe to disable or remove

If you admin Jira in a larger or older setup, I’d really value a reality check:

1. How do you review old automation rules?
2. What is the hardest part: visibility, ownership, duplicate logic, or cleanup confidence?
3. Do the native tools give you enough signal, or is this still mostly manual?

EDIT

Thank you @Marc -Devoteam- @David Nickell @Arkadiusz Wroblewski @Bill Sheboy for your detailed answers

Accepted answers

Marc -Devoteam-

Hi @Yusuf Khawaldeh

Via Global automation make a full export of all rules, as backup
Check if project is not stated on a rule
Check audit log of rules
Check the rules individually
- any components that state an error
- missing field information
Disable rules, that seem unused
Remove them if no respons on disabled rules is provided disabled rules (choose your own time frama)

Bill Sheboy

Hi @Yusuf Khawaldeh -- Welcome to the Atlassian Community!

TL;DR: start with the audit logs to find running rules and ask the rule owners for input before disabling, but not deleting rules. But, there is a lot more work to do!

In my opinion, this starts with documentation, shared accountability through collaboration, and active management of automation rules...and this is not a small effort; consider incrementally doing this work with peer team members. There have been several community questions on this topic, and I recommend searching for and reading those.

While Atlassian provides some logging of rule executions, performance insights, etc. there are limited holistic tools to support managing rules in a product / site. Worse still, with the introduction of Rovo and third-party integration features, there are many aspects impacting rule executions which are not visible in the audit logs. There are rule management REST API endpoints with which one could create rudimentary, automatic rule documentation. However, those do not include useful things like:

The ability to disable the use of the above noted rule endpoints in a site, preventing such risky practices as: self-modifying rules, run-away automated rule creation / update / deletion, etc.
Rule audit logs
Usage statistics
Public webhook events in products such as Jira to detect things like rule creates, updates, and deletes
Human-readable data on rule structures / component configurations
Human-readable names of triggers, actions, etc.
- Instead, one needs to build their own mapping tool of the JSON component names to human-readable names...as many of us have done over the years by writing our own apps to parse rule JSON. And, you would need to update it weekly / daily as the automation features change...often without notice!

In my opinion, automation rules in Atlassian tools should be considered production code assets for one's company, and managed accordingly with the same practices, change management, etc. one would use for other app code.

Starting with the guidance from @Marc -Devoteam- and @David Nickell will help. Also please consider:

Swarm with your Site / Product Admins to come up with a plan and guidelines for rule usage, documentation, and maintenance
Set up cadenced conversations with Site / Product Admins to manage rule health
Cadenced export all rules, by each product: Jira, Confluence, JSM, JPD, etc. for backup and documentation purposes
Identify which rules are enabled versus disabled
Identify which rules have run in the last N-time units, also checking the performance insights for frequently running rules; remember to check scheduled trigger rules which appear to have very long repeat cadences, such as once-per-year
Identify all people who can write rules
Identify all people who are listed as owners and actors of rules
Identify people no longer with your company who have rules assigned as owners or actors to learn to whom they delegated that role
And the very difficult / time-consuming one: meet with all rule authors to understand and document the purpose and design of every single rule. This is the certain way to confirm a rule is / is not needed.

Kind regards,
Bill

All comments

Arkadiusz Wroblewski

Hello @Yusuf Khawaldeh

From what I have seen, there is no fully safe shortcut for this.

The native tools help with triage, but they do not tell you for sure whether an older rule is still important. The audit history is limited, so a rule that runs rarely can still look inactive

Golden Rule ? Never Delete. Always Disable. You never know if you deleting something important.

David Nickell

I am not working with any at the moment to verify my hypothesis, but seems like audit log (or other details) from the global automation tab would help identify which rules are being used. In fact as I think about it, the last time I had to debug mysterious automaion behavior, this log let us know each automation execution.

Hope this helps

automation usage.png

Marc -Devoteam-

Hi @Yusuf Khawaldeh

Via Global automation make a full export of all rules, as backup
Check if project is not stated on a rule
Check audit log of rules
Check the rules individually
- any components that state an error
- missing field information
Disable rules, that seem unused
Remove them if no respons on disabled rules is provided disabled rules (choose your own time frama)

Bill Sheboy

Hi @Yusuf Khawaldeh -- Welcome to the Atlassian Community!

TL;DR: start with the audit logs to find running rules and ask the rule owners for input before disabling, but not deleting rules. But, there is a lot more work to do!

The ability to disable the use of the above noted rule endpoints in a site, preventing such risky practices as: self-modifying rules, run-away automated rule creation / update / deletion, etc.
Rule audit logs
Usage statistics
Public webhook events in products such as Jira to detect things like rule creates, updates, and deletes
Human-readable data on rule structures / component configurations
Human-readable names of triggers, actions, etc.
- Instead, one needs to build their own mapping tool of the JSON component names to human-readable names...as many of us have done over the years by writing our own apps to parse rule JSON. And, you would need to update it weekly / daily as the automation features change...often without notice!

Starting with the guidance from @Marc -Devoteam- and @David Nickell will help. Also please consider:

Swarm with your Site / Product Admins to come up with a plan and guidelines for rule usage, documentation, and maintenance
Set up cadenced conversations with Site / Product Admins to manage rule health
Cadenced export all rules, by each product: Jira, Confluence, JSM, JPD, etc. for backup and documentation purposes
Identify which rules are enabled versus disabled
Identify which rules have run in the last N-time units, also checking the performance insights for frequently running rules; remember to check scheduled trigger rules which appear to have very long repeat cadences, such as once-per-year
Identify all people who can write rules
Identify all people who are listed as owners and actors of rules
Identify people no longer with your company who have rules assigned as owners or actors to learn to whom they delegated that role
And the very difficult / time-consuming one: meet with all rule authors to understand and document the purpose and design of every single rule. This is the certain way to confirm a rule is / is not needed.

Kind regards,
Bill

Yusuf Khawaldeh

Thanks @Bill Sheboy , this is extremely helpful.

Your point about automation rules being treated like production code assets really clicked for me. I had been thinking about this as “automation cleanup”.

So what I'm understanding is that useful review needs more than just “has this rule run recently?” It needs ownership, actor information, enabled/disabled state, audit-log evidence, low-frequency rule awareness, and ideally some human-readable interpretation of what the rule is actually doing.

One follow-up for you specifically, if you do not mind:

If someone had a report that pulled together rule names, owners/actors, enabled vs disabled state, recent run evidence, audit-log error patterns, likely duplicates, and a disable-before-delete cleanup list, would that actually close a useful gap in the quarterly review process?

Or would it still be too shallow because the hard part is meeting with each rule author and documenting intent manually?

Bill Sheboy

@Yusuf Khawaldeh -- While what you described as a review / report may be quite useful, getting and maintaining some of the info would be challenging / labor intensive. For the parts which cannot be automated, delegating the data-gathering to rule owners / space admins could help (until Atlassian adds better rule management features :^)

Regarding your follow-up question, I like to invert this process for new rule creation: what problem / scenario is someone trying to solve with an automation rule? That is, "why do this?" The discussion with the requestor may uncover other / better solution approaches that do not need automation rules.

Doing this after a rule is created, while possible when chatting with the author, it may require the context of the conversation that would have happened if done before the rule was written. Take the basic example of setting a field when a work item is created: there are several ways to do that without a rule. But, if one just read such a rule, they may miss there are other rules triggered upon the field changes, leading to a tree of subsequent rule executions.

Understanding "why does this rule do X and when" helps teams and their supporting admins succeed, identify problems, and learn how to recover when Atlassian outages prevent rules from running.

Yusuf Khawaldeh

@Bill Sheboy That makes sense. I was thinking about the review mostly as inventory + evidence, but you’re right that a rule can look simple from the outside and still be part
of a bigger chain of assumptions or follow-on rules.

So it sounds like a report could help with triage, but it would not replace the intent-discovery part. Maybe the useful version is less “this tells you what to delete” and more “this tells you which rules need human review, which ones have enough evidence to disable safely, and where the missing context is.”

That is a much better framing. Thank you

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-cloud