How to use automation to recalculate SLA on a specific issue/ subset of issues?
Platform Notice: Cloud - This article applies to Atlassian products on the cloud platform.
Summary
Currently, there are times where SLAs on an issue are in an inconsistent state a manual SLA recalculation is needed to fix the SLA.
We are tracking an open feature request for the option to reset SLA from the issue view:
This article provides an automated workaround for admins to quickly perform this step as part of their general troubleshooting within the Jira issue.
Environment
Jira Service Management Cloud
Solution
The manual trigger for automation rules is now available under the Actions menu which is to the right of the Status menu on the issue view. This menu will include both manual automation rules and looped workflow transitions. With this new layout, we can now use the manual rules with more ease of access.
Scenario 1: Perform SLA recalculation from the issue view for an individual issue
Configure an automation rule as follows:
- Trigger: Manual trigger - You can further choose the subset of users who get to run this rule by choosing a group in the manual trigger
- Action: Send web request
Web request URL :
https://<instance_name>.atlassian.net/rest/servicedesk/1/servicedesk/sla/admin/task/destructive/reconstruct?force=true
The destructive recalculation is used as a last resort when the customers have the wrong SLA state or value for specific Jira issues. (force = false/true)
Graceful destructive recalculation would calculate a new SLA value and compare the timeline with the previous SLA value to see if the event order is wrong. If it is, it will sort the timeline events by their timestamp and update the SLA value with the new timeline and new state and value. It is destructive, as it would re-create the ongoing data from a new timeline. Internally it uses the same algorithm as the normal, non-destructive recalculation, to calculate the new timeline.
The forceful destructive recalculation would, again, calculate a new SLA value. But in contrast with graceful recalculation, it won’t perform any checks or try to repair the timeline. Instead, it would simply replace the old SLA value with the newly calculated one.
- Use the below headers:
- Content-Type set as application/json
Authorization set as Basic "email:API Token"
You can construct and send basic auth headers. To do this you perform the following steps:
- Generate an API token for Jira using your Atlassian Account.
- Build a string of the form
useremail:api_token
. - BASE64 encode the string.
Linux/Unix/MacOS:
echo -n user@example.com:api_token_string | base64
Windows 7 and later, using Microsoft Powershell:
$Text = ‘user@example.com:api_token_string’ $Bytes = [System.Text.Encoding]::UTF8.GetBytes($Text) $EncodedText = [Convert]::ToBase64String($Bytes) $EncodedText
HTTP Method: POST
Web Request Body: Custom data
Custom Data:
["{{issue.key}}"]
- Whenever there is a need to re-calculate the SLA for an issue, Go to Actions Menu and trigger this automation rule
Scenario 2: Perform the SLA recalculation on multiple tickets at the same time
- Trigger: Schedule/Manual Trigger
- Advanced condition: JQL
Use a JQL to filter the issues on which the endpoint will be forced
Action: Send web request (same as Scenario 1)
Important points to remember, when using the JQL or any advanced branching:
- Ensure that this is a project-level rule and not a global/multiple project rule so that it doesn't exhaust your global execution limits
- Be sure to use an efficient query that would list the affected issues. You can consider using labels for ease
- Be sure that the query isn't returning more than 1000 issues at a time by validating it. You can consider refining your query if you get more results or use labels to break down the result set.
- Ensure that you are running this in batches on a smaller subset of issues to avoid performance impact(preferably less than 200 issues)
- Be aware of the Automation service limits