How can I optimize Jira automation rules for heavy workflows?

[Emanuelwilliam]

I’ve been learning a lot about automation recently and noticed that similar challenges exist in different fields. For example, in gaming, tools like the ones described at https://delta-executor.pro/ focus on automating repetitive tasks so players don’t spend hours on the same actions.

In Jira, I see the same idea — automation saves time by handling transitions, notifications, and recurring tasks. But when scaling to large projects, I’ve noticed performance delays.

My question is: what’s the best practice for handling heavy automation rules in Jira? Should rules be simplified into smaller chunks, or is centralizing them in one global project automation better for performance?

Thanks for any insights!

[Trudy Claspill]

Hello @Emanuelwilliam 

Welcome to the Atlassian community.

Optimizing Automation Rules largely depends on what you are trying to accomplish in those rules. Other factors could be the load on your instance from users/integrations, concurrent execution of rules, the number of items being processed in a rule, ...

Are you working in a Jira Cloud or Jira Data Center environment?

Have you reviewed the service limits related to automation rules for your environment?

[Bill Sheboy]

Hi @Emanuelwilliam -- Welcome to the Atlassian Community!

Assuming you are using Jira Cloud...

Context is quite important for automation rule questions, and you did not show a specific rule or evidence for your belief it has performance delays.  If you post your rule and the audit log details, the community will be better able to make suggestions.

Without seeing the specifics, when a rule has many steps and / or performs many database reads / writes, etc., it will likely run slower than a smaller rule.  And, as there are known racetrack timing challenges with some rule features, using a longer rule may cause unexpected problems.

And...the Atlassian ecosystem can have production incidents causing rule errors or failures.  Thus, longer rules' problems may be more difficult to recover from after an outage ends.  Atlassian has recently added some automagical retry capability, but that does not cover all cases, and does not retry some work item events.

Another wrinkle is when Atlassian changed the licensing / packing model for automation (and some other products) it potentially and dramatically increased the costs for customers who were accustomed to project-scope, unlimited rule execution.  People tried to balance that with creating larger rules at high scopes, which causes its own set of challenges: cost management versus complexity and labor to handle those rule changes.

As a rule of thumb perhaps consider: 

Write one rule per each business / process problem to solve, rather than bundling into longer rules.  As other challenges happen with usage / licensing, rule length, etc., mitigate appropriately.

Kind regards,
Bill