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 what rules 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 emails in response to customer feedback comments on all work items, or just for high priority work items?

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 work item 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 or Confluence spaces you want them to run in. That is, if you have rules with Global scope but they don’t need to run across every Jira or Confluence space, change their scope to multi-space.

This will minimize wasteful rule runs, and help you get the most out 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 scope as much as possible. Consider whether rules must apply to multiple spaces or if a single-space scope would suffice. This change improves the efficiency of your rules: any events from spaces without a 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 Work Item Updated. This is because updating a work item can encompass many things, while changing a field value 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 work items or pages as early. Examples of compare conditions include the User condition, Advanced compare condition, or Work item fields condition (Jira only).

For example, if you used a condition early in your rule to check if work item 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 work items 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 Work item 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.