Automation is an awesome way to extend Jira past its standard capabilities. Apps, integrations, and scripting can help organizations eliminate manual tasks, save time, and reduce risk or the likelihood of human error. But machines can make mistakes too! What actions should be automated? How much automation is too much? As with everything in Jira, you need a strategy to keep your application healthy and happy. Here are my top automation best practices and strategies.

‍

‍

Focus on the most important actions 

Automating everything might seem like a great idea at first, but as your list of rules expands, you’ll find that actions are harder to control and maintain. Or worse, one rule conflicts with another. This situation is often hard to troubleshoot, may impact the integrity of Jira data, and certainly confuses users in the process. Too many rules create a bigger mess to manage.

Instead, I recommend the following:

• Make a list of potential actions to automate
• Record the business benefits of each
• Focus on actions that save time or money, deliver value, or increase productivity 
• Consider any risks, potential conflicts, or undesired outcomes

If an automation is conditional, relies on data outside of Jira, or needs human involvement, it might not be a strong automation candidate. Only implement the very best ideas. Start small and you can always expand later.

‍

Limit the testing risk

Now that you’ve narrowed down the list of automations, it’s time to build and test them. When testing, make sure to isolate the rules as much as possible. Testing with a very small data set can help avoid undesired impacts. For example, I thought the rule I just ran would only impact 5 issues, but instead it impacted 5,000. Oops! That’s a costly mistake to clean up. Try to limit the testing and later usage risk as much as you can.

‍

Testing tips

Always test new or updated rules in a sandbox environment first. If you don’t have a test environment, at least create a test project in your production application.

‍

‍

Next, limit rule scope to a single project. Make sure the rule works perfectly in one project before testing it in many.

Next, use conditions to further limit the scope of data. 

‍

‍

Use the “Issue Fields” condition, to limit the issues by type, status, or other common data point.

‍

‍

Use the “if / else” block to limit issues by one or many conditions. In the example, the rule is limited to issues impacting one of the organization’s services.

‍

Finally, use a JQL (Jira Query Language) condition so only a few issues are impacted. You can even hard code a single issue ID so only one issue is impacted. Just like limiting project scope, make sure the rule works perfectly before testing it on many issues.

You can also stack multiple condition strategies to limit the testing risk. Once testing is complete simply remove all the guard-rails created to limit scope.

‍

Leverage underrated features

The built-in automation in Jira Cloud and the “Automation for Jira” app in Server and Data Center contain three features I think are highly underused and underrated. All of the following help in the rule building, testing, and long term maintenance process.

Embrace the manual trigger

My favorite automation trigger is the manual one. I use it to test new automations, exactly when I want, on a single issue. Once the rule is ready to use, I simply change the manual trigger to an automated one.

Additionally, there are plenty of other use cases for the manual trigger like when not enough data exists to trigger an automation or when a human needs to make a decision first.
‍

‍

‍

The example shows a manual trigger, an action to create a new issue, and an action to transition the original issue to a different status. Consider this scenario: There’s a manually triggered rule called “Approve request”. Requests are received in project A and approved (or declined) by leadership. If the approver runs the “Approve request” automation, a new issue is created for the fulfillment team to act on in project B. Additionally the original request is moved to its final “Done” workflow status.

I like manual triggered rules because they combine the benefits of automation but put the power to run it (or not) in the hands of users.

‍

Check formulas with the log action

It’s no secret that I’m horrible at math. That’s why I use the “Log action” function at the end of rules to check formulas and any variables before actually impacting issues.

‍

‍

The last part of the example rule includes a “log action” function. In that action is a function to add three days to an issue’s creation date and show the result in a specific format. This action posts the formula’s result to the automation audit log. Now I can check that my calculations, functions, formatting, variables, etc all return as expected.

‍

Provide a useful description

How does the automation you built a year ago work? It’s hard to remember the specifics if rule details aren’t documented. I always try to provide usage details and other “good to know” information in a rule’s “description” field. This information becomes especially useful when you have many rules, there are dependencies, and multiple users create and maintain them. Further, you can also search the rules list using keywords in the description field.

‍

‍

Here’s an example of a detailed description. I usually include a sentence about what the rule does, what functions or data it relies on, any pre-conditions, and links to related internal or Atlassian documentation. It takes a little time to initially provide these details but it certainly saves time and energy in the future.

‍

Monitor errors with the rule and usage log

Finally there are three ways to check for rule problems like errors or approaching the execution limit.

First, use the “Notify on error” setting to send yourself an email every time the rule fails.

‍

‍

Next, in the System admin area, periodically visit the automation page which displays all rules across all Jira projects. Look for any rules flagged with a red diamond. This is an easy way to spot problems with rules created by others. You’ll find additional rule details in the automation audit log.

Also in the System admin area, click the “Usage” option to see the top rules that count towards the execution limit. If you’re nearing your limit, see if there are any rule inefficiencies you can improve. You may be able to lower the project scope, reduce the frequency a rule is run, or even disable a less vital rule for a while.

‍

‍

Next steps

Now it’s time to create your organization's automation strategy!

Here’s a recap of my top 10 recommendations:

1. Determine guidelines for choosing actions which are worth automating
2. Test rules in a sandbox environment or in a test project in production
3. Test rules with a single issue or in a single project before increasing the amount of data
4. Limit rule scope as much as possible
5. Use a manual trigger for controlled testing and for rules that shouldn’t always run automatically
6. Use the log action function to test formulas and variables without impacting issue data
7. Provide a useful rule description so you can quickly find and reference important details in the future
8. Alert yourself to rule errors using the “Notify on error” feature
9. Periodically check the automations list for execution problems in rules created by others
10. Visit the admin “Usage” page to monitor the execution limit and make adjustments as needed