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!
Community moderators have prevented the ability to post new answers.
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?
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For heavy workflows in Jira, it’s generally better to break large automation rules into smaller, focused ones rather than one massive global rule—this improves performance, makes debugging easier, and reduces execution delays. Also, limit triggers, use specific conditions, and avoid unnecessary actions so your rules only run when truly needed.
If you’re exploring automation concepts across different areas, you might find similar optimization ideas here as well—visit here: deltaexcutor.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Breaking larger rules into multiple smaller rules needs to take into consideration if the environment is Jira Data Center or Jira Cloud, and if Jira Cloud then it needs to consider the subscription plan.
In Jira Cloud the subscription plans have limits on how many rule executions can be run in a month. When that limit is reached no additional automation rule executions will occur until the next month. It is not possible to buy a pool of additional rule executions. The only way to get more is to modify the overall subscription plan.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
This topic is now closed as the discussion has become outdated. If you have more questions or want to continue the conversation, feel free to start a new topic. For more details on why we close older threads, check out our Rules of engagement - Atlassian Community .
Thank you for your understanding!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Community moderators have prevented the ability to post new answers.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.