Skip to main content

How to resume Jira SLA count down based on a date field (Jira Cloud & Jira Data Center)

Hello All,

Many teams use Jira Service Management to provide support to internal and external customers. Certain types of requests require agents to reach out to other internal teams to complete the work required. Agents will come across that these internal teams have their own SLAs. The team intaking the initial request can decide to pause the SLA count down for the initial request when they are waiting for another internal team. In this blog I will go over how we can configure workflow / automation to resume the SLA count down based on a date field on the ticket, which will act as a reminder for agents to follow up with other internal teams.


  • Support team uses the below Jira workflow
  • When agents decide that they need to reach out to another team, they change the status of the ticket to "Internal Wait". SLA for the ticket needs to be paused when the ticket is in "Internal Wait" status (Some will argue that the SLA should not be paused. But that's a whole other discussion which I will not discuss in this post 😃).
  • Agents then setup a Follow up date for the ticket based on the SLAs for the Internal Team they are reaching out. 
    • Ex: IT gets a request from an employee. IT team then creates a ticket with Security. Time to resolution SLA on the Security ticket is five business days. IT agent sets the Follow up date to current date + four business days (One day before the SLA or sooner based on the Priority).
  • When the Follow up date reaches, status of the initial request should change to "In Progress" from "Internal Review".
  • This will resume the SLA count down for the initial request and will notify the agent of the status change reminding to Follow up with the internal team.

Assumptions : Notification scheme for the Jira project is configured to notify the assignee of the ticket for status changes.

"Time to resolution" SLA will be configured to pause the SLA count down. During the workflow transition "In Progress" to "Internal Wait", "Follow up date" will be set by the agent. Automation will be setup to run daily to check if there are tickets where the "Follow up date" is the current date or it has passed. Then the ticket will transition into the "In Progress" status and the "Follow up date" field will be cleared.

Configuring Time to resolution SLA

Time to resolution SLA will be configured to pause when the ticket goes to "Internal Review". Also, given that we have not added "In Progress" status in pause or stop conditions, SLA will keep counting during "In Progress".

Configuring the workflow

Transition screen will be added with the "Follow up date" field as a mandatory field during the transition from "In Progress" to "Internal Review". 

Configuring the automation

Automation will be scheduled to run everyday at 1:00 AM. Automation will check if there are tickets that matches the below JQL.

status = "Internal Wait" AND "Follow up date" <= now()

This JQL returns tickets where the "Follow up date" is equal to the current date or it has passed the current date.

All tickets that are returned from the JQL will change status into "In Progress" and clear the "Follow up date" field value. This will resume the SLA count down for the ticket and notify the agent for the status change. This will act as a reminder for them to follow up with the internal team they are waiting on.

Thanks for taking your time to read this blog. Hope this helps !


Popular posts from this blog

How to export a list of Jira custom fields to csv (Jira Data Center)

 Hello All ! As a Jira administrator it is very important to keep an eye on the number of custom fields you have in your instance because the number of custom fields directly impact your instance performance. Atlassian also has confirmed this in their documentation .  One of the important strategies to keep your custom field number low is to reuse them as much as possible across projects. When you get a request from a user to create a custom project, you can provide a list of custom fields upfront, and ask the user to choose existing fields instead of creating new ones. Out of the box, Jira doesn't provide an easy way to export the custom field list to a csv file to share with non Jira admin users. In this blog I will share how I exported all Jira custom fields into a csv file using Jira REST API and Python. This solution was tested on Jira Data Center version 8.x, Python3 and Windows 11. Let's see how we can get the custom field list in 3 easy steps. Note : I assume that you

How to send a survey with multiple questions in Jira Service Management (Jira Cloud & Jira Data Center)

Hello All, Out of the box Jira Service Management only allows to add one question for the customer satisfaction (CSAT) survey once a ticket is resolved. But most teams like to collect feedback on different aspects of the support provided to the customer by adding more than one question. In this blog I will go over a workaround to send multiple questions to the customer when a ticket is resolved.  Scenario Support team uses Jira Service Management to work on customer requests. Once a request is resolved an email needs to be sent to the customer with a survey including multiple questions. Survey response needs to be tied to the Jira ticket number. Solution In order to send multiple questions we will use a google form.  When the ticket is resolved the reporter will get an email with a link to a google form containing the survey questions.  The first field of the google form will contain (this will be autofilled) the issue key where the user received the survey. Given that we are not using

How to setup Jira SLAs for global teams across multiple time zones (Jira Cloud & Jira Data Center)

Hello All! Being a global company creates the need to have IT teams across different parts of the world in different time zones. When you have team members working in different time zones you also need the ability track SLAs for the work they do. In this blog I will go over a solution to track Jira request SLAs for global teams across multiple time zones. Scenario: IT department have three teams in three different time zones (Barcelona, New York,  Los Angeles).  Employee requests are processed by the IT team assigned to the location of the employee. All three IT teams work from 9:00 AM to 5:00 PM (Monday - Friday) in their respective time zones.  Every request submitted to IT needs to be resolved within 40 business hours.  Requests can be transferred to another team and the SLA clock should be updated to use the respective time zone of the teams location.  Office Location Timezone Hours (M-F) Time to resolution Barcelona CET 9:00 AM - 5:00 PM 40h New York EST 9:00 AM - 5:00 PM 40h Los