One of the best features of Jira Service Desk are the integrated automations. They are easy to set up and can help automate much of the work, from assigning tickets to closing resolved ones. So, let’s explore what we can do with them!
Templates for automation rules
A great starting point for any of your use cases are the rule templates. These are perfect examples to the capabilities of the tool which you can easily tweak to match your needs.
First, let’s go find the automations panel. Open your project settings by clicking on the cog, on the bottom left of your project view. This will only be available if you’re a project administrator. Once you have the project settings view, click on “Automation” on the left panel.
This works with other sections of the administration screen. For example, you can replace the word “automation” in the link by “sla” for the SLAs, “confluence-kb” for the knowledge base, and “request-types” for request types.
Alright, now back to our automations. Let’s have a look at the list of pre-defined templates. You can click on “Add rule” on the top right of your automation screen to find these:
As you can see, the titles are self-explanatory and you can choose the one that sounds closest to your use case, or start from scratch by choosing “custom rule”. You can then modify it for your service desk.
Triage requests sent by email
For our use case, we’ll automate “Triage requests sent by email”.
We can see that an automation rule has three logical parts:
When: Defining what triggers the rule.
If: Once the rule is triggered, we check if a set of conditions are respected.
Then: The actions to execute.
In each one of these sections, you have a set of choices that are determined by what you selected in the previous options. Since we chose “Triage requests sent by email”, we see that a basic use case is already prepared, so we’ll only have to adjust a few things to make it fit.
We won’t modify the “When” section, as we want the triage when the issue is created.
We will add two conditions, a JQL (Jira Query Language) filter which makes sure that the issue was created from an email and the subject contains the words “not working” (summary ~ “not working” AND request-channel-type = email). Note that we don’t need to specify the project in this filter as it’s automatically applied to tickets in the current service desk project.
We can then add a condition to check if the “Reporter language” is English.
If these conditions are met, we will run some actions like “Edit request type” to set it as “something is broken.” We can also “edit the issue” to automatically assign these issues to a certain agent in the team, and finally “Send email” to send an email to the customer, saying that we’re taking care of his ticket. We’ll reply in English, since we know that they used English to communicate with us.
The possibilities are almost infinite and easy to set up, so feel free to try them! You’ll probably find a way to automate a big chunk of your tasks.
How to avoid infinite loops
You can set up two rules, where the first rule’s actions trigger the second’s conditions. This can become problematic when the second rule’s actions trigger back the first one’s conditions, it will run the same action again, which in turn will trigger the second rule one more time – and it never ends….
You have to be careful with your automations by properly testing them on a staging environment before pushing them to production. If your use case allows it, go to your automation rule, click on options and uncheck “Allow this rule to be triggered by other rules.” This will stop an infinite loop from happening.
How to troubleshoot automation rules
If your automation is not behaving as expected, you will have to do some troubleshooting. Click on the “View log” button on your automation screen and then “Show details.” This will give you all the details you need to understand why your automation was or was not executed.
The limitations of automation rules
A few things are still missing from automation – and that’s probably by design. For example, you cannot have as a condition an issue update. This is normal, as it would be too heavy on the resources to test all automation conditions every time you edit a simple field in any issue. But you can be creative in order to make it work.
Our favorite workaround is when you want to run automations when you update a field. You can make that field non-editable by removing it from the edit screen, then create a self-transition on your workflow “Edit field X” that would allow you to edit that particular field. That means that the issue was not updated, but rather that it transitioned through the workflow, which can be used as a trigger to run your automations. This is particularly useful if calculating fields based on other fields, and you want that to remain up-to-date. For example, if your priority field is based on “impact” and “urgency”, and you would like to change priority every time you change one of these two, you can set up this type of workarounds.
A different option would be to install the Automation add-on, which has a free lite version available that would allow you to do a bit more.
Otherwise, you can call an expert from Valiantys for some help setting up your automations and workflows! If you need a bit of help, just fill out the form below to get in touch!