When running a service desk, there are many mundane and repetitive tasks that can end up wasting a lot of your team's time. For example, after a request is closed, if the customer adds a comment afterwards, the request needs to be reopened so it will be placed back into the queue for agents to work on again. Normally, this would require either an agent to manually reopen the request, or you, as the JIRA administrator, to configure the workflow used by your service desk project to automatically reopen the request. This can be tedious for the agents, and overwhelming for you, if there are many service desk projects needing this kind of automation.
The good news is, JIRA Service Desk has a process automation feature that greatly reduces the complexity and allows each service desk owner (users with Administer Projects permission) to set up the automation rules, as shown in the following screenshot:
Follow the steps below to set up automation rules:
- Browse to the project administration page of the service desk you want to set up automation rules for.
- Select the Automation option from the left panel.
- Click on the Add rule button to create a new automation rule.
- Select from one of the pre-made automation rule template from the dialog box, or select the Custom rule option from the button to create one from scratch.
- Enter a name for the new automation rule.
- Configure the automation rule and click Save.
There are a number of things to consider when configuring your automation rule. Firstly, each rule is made up of three parts called WHEN, IF, and THEN, as shown in the next screenshot. The way to think about this is that your rule should read something like this: when something happens on a request, if the criterion is met, then execute the following actions. So, if we take the customer adding comment to a closed request example, the rule may be something like this: when a comment is added, if the request is in Closed status, then transition the request to Re-opened.
You configure these components of the automation rule by clicking on the UI elements representing each component. There are a few points to keep in mind when designing your rule:
- You can only have one WHEN, which acts as the entry point for the rule. However, it can have multiple triggers, so each rule can be triggered by more than one action.
- You can have more than one IF (as ELSE IF), so you can set up multiple criteria to evaluate when the rule is triggered.
- You can have only one THEN, which can have multiple actions to execute, as shown in the following screenshot:
Other options include the following:
- Whether the rule should be run as the user who triggered it or a dedicated user set for the service desk project. As not all actions can be run as the user who triggers it, especially if the user is a customer, it is safer to use the project default option.
- Whether the rule can be triggered by another automation rule. This is very useful as it allows you to chain multiple rules together to automate your process. However, you need to be careful and make sure you do not have rules that will trigger off each other and get stuck in a loop.