Page tree
Skip to end of metadata
Go to start of metadata

See our new Create your SLA document in which we describe each step to create and to configure an SLA contract according to your needs.

SLA definitions can be created under Time to SLA Menu > SLA Configuration.

TTS SLAs are based on JIRA workflows. 
After selecting JIRA Workflow, click on Add New SLA Definition button. 


SLA definition form will be displayed as below.

Freezing SLA

The toggle button changes the state of the SLA as either Active or Frozen. SLA data will not be calculated for this SLA until it is re-activated. SLA data of uncompleted issues will be lost after the first transaction in the issue. Frozen SLAs will be shown grayscaled in the SLA list.

  • Description  is the name of the SLA which will be displayed to identify.
  • Priority , SLAs can be differentiated according to issue's priority 
  • SLA Start , SLA can be started via  status or given date or comment.
    • If status option is selected, status (multi-select) drop down will be displayed and the status(es) that will start SLA can be selected. If any issue's status changes to one of the selected statuses, then SLA will start immediately. 
    • If 'date custom field' ('date field' for  TTS 9.0.0+) option is selected, the dropdown will be displayed showing all applicable date and datetime custom fields. SLA starts in the time of selected custom field's value. 
    • If comment option is selected, dropdowns will be displayed which you can select comment's properties to take into account to start the SLA. First comment that matches the selected properties will start the SLA.
  • SLA End , similar to SLA Start, SLA can be finished via status or date custom field or comment.
    • If the status is defined, then the SLA will end when the issue's status changes into selected status or changes into one of the selected statuses.
    • If 'date custom field' ('date field' for  TTS 9.0.0+) option is defined for SLA End, then any issue's SLA will end in the time of selected custom field's time value. 
    • If comment option is selected, dropdowns will be displayed which you can select comment's properties to take into account to end the SLA. First comment that matches the selected properties will end the SLA.
Please bear in mind that SLA End Date is not the 'negotiation date', it is the 'actual end date' of the issue. 
Selected date custom fields, statuses and comment will determine the actual start/end date of the SLA. 
Start/End SLA custom field support is available since TTS 5.10.0 for JIRA 6.3 - 6.4.12 or TTS 6.5.0 for JIRA 7.x
Start/End SLA comment support is available since TTS 7.0.0 for JIRA 7.x
  • SLA Value (SLA Goal for  TTS 9.0.0+) defines the end of SLA contract. There are three alternatives for SLA value. 
    1. The duration of SLA as time string (e.g. 2d 4h 30m). This is the static SLA value and this value is used for all issues that are the topic for the SLA.
    2. SLA Negotiation Date Field (Negotiation Date for  TTS 9.0.0+) Sometimes rather than SLA duration value, a deadline (date/time field) can be more meaningful.

      If the selected field is date only field (such as due date or date custom field) then by default time section will be 00:00 AM. However, 'Time Part' field will be seen to set time part if date only field is selected.


    3. SLA Value from TTS - Text String Custom Field (Dynamic Duration for  TTS 9.0.0+) is another alternative to SLA value. This is the dynamic SLA value. This field can be used to change SLA's value (duration) per issue. Refer to Adding Time String Custom Field to add a TTS - Time String Custom Field to select a Time String Value as SLA Value.
  • Time to SLA Color (Critical Zone for  TTS 9.0.0+)  determines when the color of the SLA will change, according to the time remaining to the SLA Target Date.  For example, an SLA with SLA value of 5 hours will change to orange when the remaining time becomes 1 hour when this field is set to 80%.

  • Working calendar (Calendar for  TTS 9.0.0+), can be selected as 7x24 or any "Working Calendar" which can be defined in 'Calendar' link in Time to SLA Plugin menu.

  • Multiple transitions (not available for TTS 9.0.5+) , should be enabled if the issue can have multiple transitions till the end (according to workflow). Assume we have Open, In Progress, Resolved and Closed statuses in workflow, and we want to define SLA from 'Open' to 'Closed' which can be done by at least two transitions: 'Open' -> 'In Progress', then 'In Progress' -> 'Closed'. 

  • Calculation Method  You can select which method should be used while calculating working durations for SLA. Possible options are:

    • All Cycles: This method will take cumulative sum of the durations of all cycles between origin and end statuses.
    • First Cycle: This method will calculate the duration of only the first cycle between  origin and end statuses. 
    • Last Cycle: This method will calculate the duration of only the last cycle between origin and end statuses. (6.40.0+)
    • Largest Span: This method will calculate the largest interval between first origin status and last end status occured in issue history. (6.40.0+)
  • Also, additional JQL conditions   can be added to  SLA definition in order to filter issues that SLA should be applied. For instance, issuetype in (Bug, Task)  JQL definition will make SLA only valid for issues of which the issue type is either Bug or Task. 

    Please refrain from using clauses like ORDER BY in your JQL conditions.

  • Asynchronous update   (6.40.0+)  When enabled SLA calculations will be executed asynchronously after issue events.  Since SLA updates will be executed asynchronously you might expect better issue load times but in exchange changes on SLAs will be reflected with a delay which is nearly one minute. This option is only recommended when any field in SLA's JQL condition gets updated during workflow transitions (eg. if you use priority in your additional JQL condition and update the priority in a workflow transition)

What is the difference between SLA Start/End and SLA Deadline Fields?  
Even though they seem to be similar, they are not. 

      • SLA Start Date Field is the field which stores actual start date of the operation. In some scenarios, the operation related to the issue can start before the issue creation or issue's arrival to any status.
      • SLA End Date Field is the field which stores actual end date of the operation. Similar to SLA Start, the process can continue after the issue's resolution
      • SLA Negotiation or Deadline Date Field stores the expected SLA target date. If this field is selected, the counter will count until the end of date/time value that this field holds.

There is no limit on the count of defined SLAs. All SLAs are grouped by workflow selection.

Besides the cog icon, there are some icons/lozenges which indicate whether there is an additional configuration for SLA. 

JQL means there is additional JQL defined for this SLA.

PAUSE means there is/are paused status(es) for this SLA.  

RESET means there is/are reset field(s) for this SLA. 

              means there is notifier for this SLA.


By clicking cog icon, SLA definition can be edited, deleted, cloned, moved to another workflow, etc.

Also, there are handy settings like, Pause SLA, Reset SLA , and SLA Notifier which are described below

Pause SLA (Set Pause Conditions for TTS 9.0.0+)  link displays a dialog in which SLA can be configured to have paused staus(es). If the issue reaches to one of these selected "Paused Statuses" the timers will immediately stop to count for SLA. 

Reset SLA (Set Reset Conditions for TTS 9.0.0+)  link displays a dialog seen below. When at least one of the selected fields of the issue changes, the SLA timer resets immediately. 

Move SLA option changes the corresponding workflow of the SLA definition. It is accessible through change workflow link in the cog icon in SLA definition page.

  • No labels