Summary

Currently, there are times when SLAs on an issue are inconsistent, and a manual SLA recalculation is needed to fix the SLA.

• SLAs in Jira Service Management are missing or disappear

This article provides an automated workaround for admins to quickly perform this step as part of their general troubleshooting within the Jira issue.

Building the automation

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.

• Transition an issue
• Manual trigger rules are moving

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:

      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:

           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.

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

• JSDCLOUD-194 - Ability to reset the SLA