Recalculate inconsistent SLAs with Automation in Jira Service Management

Summary

Quickly resolve inconsistent SLAs in Jira Service Management with an automated workaround to recalculate SLAs.

Solution

Use a manual trigger to recalculate the SLA for a single work item

Manual triggers can be accessed from the Actions menu, right next to the Status on the work item view. Configure an automation rule as follows:

1. 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.

2. Action: Send web request.

   • Web request URL :

     1 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, perform the following steps:

       1. Generate an API token for Jira using your Atlassian Account.

       2. Build a string of the form useremail:api_token.

       3. BASE64 encode the string:

          • Linux/Unix/MacOS:

            1 echo -n user@example.com:api_token_string | base64

          • Windows 7 and later, using Microsoft Powershell:

            1 2 3 4 $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:

       1 ["{{issue.key}}"]

3. Whenever the SLA for a work item needs to be recalculated, Go to the Actions Menu and trigger this automation rule.

Perform the SLA recalculation on multiple work items at the same time

1. Trigger: Schedule/Manual Trigger.

2. Advanced condition: JQL.

   Use a JQL to filter the work items on which the endpoint will be forced.

3. Inside the JQL condition branch, add the Action: Send web request. Use the same configuration from step 2 in the previous rule.

   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.

We are tracking an open feature request for the option to reset SLA from the work item view:

• JSDCLOUD-194 - Ability to reset the SLA

Related article:

• SLAs in Jira Service Management are missing or disappear