Best practices for optimizing automation rules

The following best practice guidelines will allow you to optimize your automation rules, so that they run more smoothly and are easier to manage.

Manageability

Plan your rules before creating them

Planning your automation rules ahead of time will help you work out the rules that you must have, and where you can instead combine rules by using conditions.

Start with your team’s work processes and the actions you want to occur, then work backwards to what events you want to trigger those actions. For example, do you want to send out emails on every customer feedback comment on an issue, or just on issues of high priority?

Align your automation strategy with your business and operational processes

Automation rules are designed to help your business and operational process work more efficiently – they should align. A review of your automation rules should occur alongside reviews of your business and operational processes.

Staying within usage limits

Add conditions to rules

Use conditions to ensure that actions occur exactly when you want them to. Only rules that perform a successful action will count toward your usage, so this will help you make the most of your monthly limit. For example, in Jira Automation, consider adding a filter for issue status, to only run for particular statuses (like To Do, or In Progress), 

Check the scope of your rules

Make sure your rules run only in the Jira projects or Confluence spaces you want them to run in. For example, if you have a global rule, consider if the rule needs to run across every Jira project/Confluence - if it doesn’t, change it to a multi-project or multi-space rule instead.

This will help minimize wasteful rule runs, and help you get the most of your monthly usage.

Disable rules

Monitor your rules, and identify the ones that are either running too much, or rules that you don’t need, and disable them to prevent wasteful rule runs.

Performance

Restrict the scope of your rules

Avoid using global rules as much as possible. Consider whether rules must apply to multiple projects or spaces, or if a single-scoped rule would suffice. This change improves the efficiency of your rules as any events from projects or spaces with no matching rule are filtered out. As a result, there are fewer rules that need to be queued for execution.

Combine Rules

Each rule may function perfectly well alone, but rules can often work better together. Are you able to use the same rule for multiple current rules? For example, you might have a rule that branches on the current rule and then runs conditions and actions underneath.

Select an appropriate trigger

Some triggers are more specific than others, so if your situation requires a specific trigger, avoid using a more general one. For example, in Jira automation, Field Value Changed is far more economical than Issue Updated. This is because an issue update can encompass many things, while a field value being changed is a more specific kind of update.

Use Compare conditions as early as possible in the rule chain

You want to use conditions that compare one value with another early in your rule, to eliminate possible issues or pages as early. Examples of compare conditions include the User condition, Advanced compare condition, or Issue fields condition (Jira only).

For example, if you used a condition early in your rule to check if issue type = Bug, this makes your rule much more efficient because you’re eliminating all non-bugs from your rule early.

Ideally, you should be chaining these conditions at the start of your rule to exclude all the issues you don’t want to operate on as early as possible. 

Move checks that require more processing further down the rule chain

Conditions that check singular fields, such as the Issue fields condition (Jira only) or User condition, are the simplest to run so these should be earlier in your rule chain.

The Advanced compare condition, and those involving query languages like the JQL and CQL conditions, require more processing. Try to avoid these if possible, or push them to the back of the chain.

For example, checking if type = Done (a JQL condition) requires more processing than comparing {{issue.status.name}} equals Done (an Advanced compare condition).

Use branches sparingly

Only add branches to your rule where you absolutely must. This is because branches spawn new processes in your rules. Branches are useful if you’re combining rules, but if it doesn’t serve a purpose then it can have negative effects on performance.