Best practices for optimizing automation rules
The following best practice guidelines will allow you to optimize your Jira automation rules so they run smoothly and are easier to manage.
Plan your rules before creating them
Planning ahead will help you work out what rules are a must have and where you can combine rules by using conditions.
Start with workflows and actions you want to occur, then work your way backwards to how you want each action to be triggered and when. For example, do you want to send out emails on every customer feedback comment on an issue or only on issues of a high priority?
Align your automation strategy with your business and operational processes
Automation rules are there to help your business and operational processes work more efficiently; they should align. A review of your automation rules should occur alongside reviews of your business and operational processes.
Restrict your rules to specific projects
For existing rules, check if you can change their scope from global to project-specific. Any events without a matching rule will be filtered out, optimizing your automation queue.
You can set the scope to a specific project, multiple projects, or all projects (global).
If a rule applies to a small number of projects, set the scope to these projects only. This restricts rule execution at a very early stage.
If a rule in fact applies to many or all projects, try merging similar or duplicate rules and then apply them globally.
Combine your rules
If you have two or more similar rules, merge them into one to lower the number of rules in your instance.
Let’s have a look at these separate rules and how they could be combined into one:
|Rule 1||Rule 2||Rule 3|
The combined rule would look like this:
For an issue with a To do / In progress status, with SLO within 5 days:
Pay attention to the order of your conditions
We recommend using conditions that will filter out the highest number of issues as soon as possible in the rule chain. Note that:
For some triggers, you can limit the number of actions that trigger the rule. For example, the Field value changed trigger can be limited to only the Issue transition action.
Some Compare conditions limit the number of issues more than others. In most cases, checking if an issue is assigned to a specific user limits the number of issues more than checking if its statusCategory is different than Done. That’s why you should start by checking the assignee.
Some conditions may be more expensive to execute (for example, JQL conditions) and should be performed as late in the rule chain as possible.
Use branches sparingly
Only use branch rules if necessary. A good use of branches is for combining rules, as shown in the tables above. In other cases, branch rules can slow down your instance.
Avoid too many actions
When you need to perform multiple operations, try to perform as many of them as you can in each action. Thanks to that, you can reduce the number of actions that need to be performed to execute a rule. For example, you can edit multiple issue fields in a single Edit issue action. The Transition Issue action also allows you to edit issue fields.
Avoid scheduling rules with long runtime for peak hours
Try to schedule your rules outside of peak hours, especially if you expect them to execute for a long time. During peak hours, your instance might already be overloaded. Use schedule rules to do that.
Cleanup and limits
Expire audit log items
By default, the audit log is configured to never expire. We recommend that you change it to any other value to expire old entries. Without it, your audit log can quickly grow to a size that impacts performance.
Clean up regularly
Review your rules on a regular basis and remove the ones that have high performance impact and low value. You can use database queries to quickly find such rules. Learn more about rule statistics
Watch out for service limits
Service limits have been carefully selected and changing them might result in performance issues. Change them only if you need to. Learn more about service limits
Avoid using automation as a batch processor
You shouldn’t use Jira automation as an issues batch processor. This includes rules with such broad triggering filters that they near throttling limits. These rules take a long time to execute and they might be throttled, which would result in some issues not being processed at all. Learn more about service limits
Optimize your JQL queries
Try optimizing JQL queries used in triggers and conditions. These queries can be executed very often, which impacts performance. Learn what impacts the JQL performance
Make JQL queries more specific
When you create a rule with a JQL component, make sure to check how many issues are returned by the query (unless you use smart values). If the number is high, try making the JQL query more specific.
Avoid synchronous execution
Only use synchronous rule execution if necessary. It’s enabled by the following setting:
Watch out when allowing rules to trigger one another
You can configure a rule to be triggered by another rule (setting shown below). When you have many rules with this setting enabled, this might result in an uncontrollable chain rule execution. This is especially important for rules with very generic triggers, such as Issue updated.
Watch out for web-based integrations (webhooks)
Only use web-based integrations (webhooks) if necessary, as they might significantly slow down rule execution.