Automations | ACP-420 Jira Service Projects

After a one week hiatus for Team25 down in Anaheim (more on that on Thursday!) we’re back with some ACP-420 studying, this time focusing on Automations. Automations exist in a number of Atlassian products (Jira, Jira Service Management, Jira Product Discovery and Confluence) and allow the system to take action for us.

Personally I use automations very frequently in Jira Service Management. Most commonly I use them to assign tickets to agents via a “load balancing” assignment rule. This helps ensure that when a new ticket comes in it gets assigned to the agent with the most bandwidth (e.g. least number of tickets). I also use them extensively in Confluence to generate new pages on a regular basis, assign labels and identify content that is stale.

These, however, are by no means the only things Automations can do for us. Other examples include creating Jira tickets when a Confluence page is published, generating sub-tasks at the push of a button, calling webhooks, changing the work item status and more. 

Before we begin

The best way to learn about automations is to go play with them. Every tier of Jira Service Management Cloud allows for automations (although the lower the tier the less automation runs you get per month). Make some time (right now!) to go open Jira and explore what automations have to offer. This will give you a good understanding of what’s in there, and what is possible.

You’ll also be able to browse automation templates. These are a great starting point for uncovering what is possible, and also a great starting point if you’re not quite sure how to get something off the ground.

It can also be hard to figure out what to automate. I start this process by thinking through what I do (or what my team does) on a daily basis, and identifying things that are repetitive and clearly defined. Once I have a list of these I sit down and ask myself which one is the biggest (or most annoying) and see about automating it.

When you’re working with a team be sure to get feedback from them on what should be automated, and what is worth automating. Getting more perspective at this stage is incredibly important, as the team will have a better view of what is a time waste than just one person. It can also have the great side effect of getting folks interested in finding more things to automate. I’ve seen groups go from “we don’t know it exists” to saving loads of time simply by having some engagement around automations.

Automation Scope

Automations have two main scopes - Global and Project.

Global automations can be created by Product admins and allow the automation to run across an instance, or across a specific list of projects. In my mind this is similar to how schemes let projects share configurations and allow Product admins to automate tasks across projects. This is incredibly useful when you have a number of projects that do something similar - for example every new engineering project has a separate Jira project, or you have multiple customer service teams. When you go this route just be sure to let folks know there are global automations! If folks aren’t aware they’re running (or what they do) you’ll get a lot of very confused questions about why things are changing.

Project automations are scoped to a single project and can be created by either Product or Project admins. Most of the time people will be making a project admin as this is their level of access. It’s important to remember these can only impact a single project. If you have the need for an automation to run across projects you’ll need to work with a Product admin to make a global automation. Project scoped automations allow individual teams to determine what they need to do without impacting other groups. This gives you the ability to tailor how the automations work to fit your unique needs.

Anatomy of an Automation

There are two required parts to an Automation - triggers and actions, as well as two other optional components - conditions and branches.

Triggers - Triggers are what tell Jira to run the automation and are required for every automation.  Common examples include a manual trigger (e.g. someone clicks a button), when an issue is created and via a schedule. There are, however, many other triggers! Triggers can also fire when something happens in github, a task is reopened and more.

Conditions - Conditions let you control when an automation should continue and are optional. For example you may have a condition that the automation should only proceed if a specific user is assigned to the ticket. Conditions also allow for “if/then” logic, which lets you have different outcomes for a single automation depending on different information. For example you could assign a ticket to one user if it comes from a specific country, and to another user if it comes from a different country.

Branches - Branches are optional and allow an automation to run against multiple work items that meet some criteria. For example you could have a branch that runs against every ticket that meets specific JQL criteria, or run against every ticket that has a specific Epic as a parent. I commonly use branching to update child work items with a single click.

Action - Actions are required and are what the automation does. Actions include things like changing the value of a field on the work item, moving a ticket through a status and many others. Typically actions are what people think of when they think of an automation as they do something in the system. 

Audit Logs

Every time an automation runs Jira records it in the audit log. This is an incredibly useful tool as it records every time an automation is triggered. This lets admins chase down bugs or other problems in the automation. They can be a bit bare at first, so I typically recommend folks include a step in their automation that adds to the log. This helps ensure useful information is begin recorded (or at least information the admin can follow up on later to see what has happened).

Other Items

In addition to its scope and setup, automations offer some other options we need to be aware of.

Run as - By default automations will show up in logs as “Automations for Jira”. You can, however, change this on an automation-by-automation basis. For example you could have it run as the person who triggers it, or another user (or even a service account). Keep in mind this is what appears in the work item history, so be careful about selecting a person as this could be confusing when reviewing logins!

Failure notification - from time to time an automation can fail. In this case Jira will send an email to someone (by default whoever creates it) letting them know about the failure. This is a very useful notification, but you can, however, change who receives it. 

Who Can Edit - You can control who has the ability to edit a specific rule. This is useful if you want to ensure the rule is accidentally (or otherwise!) changed.

Check to allow - By default automations will not trigger automations. This is a safety mechanism to ensure automations don’t run wild… you can, however, check this box to allow automations to “chain” - or trigger others. This can be useful in cases where you want to automate longer processes or concepts.

Additional Information

There is some additional information we should know about automations.

Step limits - Automations are limited to 65 steps (any combination of triggers, conditions, branches or actions). While I’ve personally never run into this particular limit, I can easily see more complex/sophisticated automations pushing this limit. This requires admins to sit down and determine what is really needed, or what can be broken out into different automations.

Run limits - Except for Enterprise every tier of Jira Service Management cloud has a limit to the number of times an automation can run. See this link for the current limitations, but these are important to keep in mind (Especially if you’re on Standard or Free!).

Time - Jira evaluates automations as they meet their trigger condition. This means that if you have a lot of automations that trigger on issue creation it can take a while for them to run. This can make things frustrating as automations may seem to be delayed - when in reality Jira is just checking to see what it should do. I you notice significant delays go check the audit log to see how long things are taking and see if you can remove or adjust things to speed it up.

Parting Thoughts

Automations are something I need to take a deeper look at, mainly because I’m sure there’s more I can be automating. Many groups I work with, however, don’t use them at all either because they don’t know what they can do, or they don’t know automations exist. I find this to be a massive loss for those groups as there is a lot of work we (as humans) don’t need to do!

Make time to get familiar with automations and you’ll be surprised at what you can do (and what you don’t have to do any more).