Page tree

Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Tip

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.

...

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

    Panel

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


    Anchor
    Asynchronous Update
    Asynchronous Update

  • 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)


...