Jira Service Management Automation
Now the full power of SIL can be brought into Jira Service Management! New features have been added when creating custom automation rules from within Service Management.
This feature allows the Jira Service Management automation rules (and Power Scripts for Jira) to work in new powerful ways! It also keeps things simple and clean by allowing you to keep all the automation configurations located in a single area within Jira instead of some automations living outside of the Service Management project settings. It also allows you to track the execution of the Power Scripts automations using the standard Service Management automation logs.
Why should I care?
New triggers
New predefined triggers have been added to the WHEN condition
Create your own custom IF conditions using SIL
Create your own custom Then actions using SIL
Simplicity - keep automation settings in a single location
Logging - use standard Service Management automation logs to track Power Scripts executions
Power - using standard Service Management WHEN conditions, SIL scripts can be executed in ways that were never possible before. For example, now scripts can be triggered when an SLA is breached.
WHEN (Trigger)
We have built new automation triggers in Jira Service Management that will greatly extend the functionality of the Service Management automation rules. Because of the way these triggers run in Jira they are not scripted and work out-of-the-box the same way a standard automation trigger works in Service Management. The following triggers have been included:
Issue Assignee Changed - This condition will trigger if any change is made to the issues assignee field.
Attachment Added - This condition will trigger if any attachment (public or private) is added to the request.
Work Logged - This condition will trigger if any work logs are added to the request.
Issue Field Changed - This condition will trigger when the specified field is changed. This can be used for any custom field or standard issue field including assignee, summary, description, etc. Here is a list of
Setup/Configuration
Jira Service Management WHEN conditions operate like an event listener. Because of this they must be pre-registered with Service Management and therefore they do not run off of scripts but are pre-built. This makes using one of the new triggers created by Power Scripts for Jira Cloud exactly the same as using an existing trigger, just select it from the list.
IF (Condition)
For the IF conditions a new condition called "SIL condition met" was added. This new condition will trigger a SIL script to confirm the issue matches the specified parameters and the automation should continue. Despite there only being one option for this the condition is backed by the full power of the SIL language. This means that extremely complex conditions can be created using SIL that would not otherwise be possible within Service Management.
Condition Script
To create a SIL condition script simply return a true if the condition has been met and automation should continue or, optionally, return false if the condition was not met and the automation should stop.
if(issueType == "Bug") {
return true;
} else {
return false;
}Setup/Configuration
To set up a new "IF" condition, click the "Add condition" button at the bottom of the Edit IF screen
Select "SIL condition met (PS)" from the list of available triggers then click Add
Select your condition script
Press Confirm
Save the changes to your custom automation
Example
Lets say that whenever a customer from a very important client creates a request you would like the priority of the request to be set to "Highest". You can not always rely on the customer being associated with an organization because the customer could be new and the Service Management agent may not have associated them to an organization. One possibility would be to check the domain of the customer to see if it matches the domain of your important client.
string reporterEmail = userEmailAddress(reporter);
if(contains(reporterEmail, "@companydomain.com")) {
return true;
}The code above will return true if the reporters email contains the test "@companydomain.com". It was not necessary to add a false condition in this example since the condition will not be met unless a true value is returned. To finish this example and set the priority to "Highest" requires the THEN condition to be configured.
There is an option for the Service Management automation to run as a default user. This means the script will always run in the context of that user and not the user executing the rule.
It is important to understand if it is important to understand who the user executing the rule is when setting up your automations.
THEN (Action)
At this point the automation has been triggered (When), all conditions about the issue have been met (If), so now it is time to perform the automated action (Then). Power Scripts adds an additional action called "Execute SIL script" which does just what the name implies, it executes a SIL script. However, when this script is triggered it run in the context of the issue that it was triggered for. This greatly simplifies the script that needs to be written.
Setup/Configuration
To set up a new "THEN" condition, click the "Add condition" button at the bottom of the Edit THEN screen
Select Execute SIL script (PS) from the list of available actions and click Add
Select your action script
Press Confirm
Save the changes to your custom automation
Example
This example sets the assignee of the request to be the last Service Management agent to author a comment. Checks in the IF condition would make sure the user was an agent prior to executing this action.
JComment com = getLastComment(key);
assignee = com.author;Because of the option to run scripts as a default account this script looks a little different.
Instead of just grabbing the username of the person who triggered the comment rule, like this:
The above example gets the username from the last comment added to the issue. This is done because the currentUser() routine will always return the name of the default user that has been configured to run the automation rule (assuming that is the way the rule has been configured). If the rule was not configured to use a default user then the currentUser() method would work.
Contents