Service Level Management (SLM)

the service level management functionary provides the ability to track the business duration within or without a specific schedule that a record may take between various conditions the sla definitions that are used to define the parameters of this feature can be run in a defined timezone and can then be started, stopped, paused or cancelled based on a condition in doing so and depending on the status of a sla, it can then update records, trigger notifications or otherwise based on its status consideration purpose an sla is typically used to define an expected level of service between a provider and its customer if your organisation is the provider and you have an agreement with your customers to close all priority 3 incident tickets within 2 business days from time of creation, then you will need to define an sla that include the following parameters start condition when a priority 3 incident is created stop condition when incident is closed (you typically may want to apply a pause condition when the incident is resolved) duration 2 business days ongoing maintenance you can have one or more slas running on a ticket at any given time in its lifecycle an example is that for itsm incident process, there are typically 2 slas where one is for response and another is for resolution if there are different sla definitions for different priorities and if your organisation's incident process runs with priorities 1 to 5 with each priority having 2 types of slas, then you will end up with 10 sla definitions just for the incident process note that you can also configure an sla definition to only apply for when it is for a specific customer and specific service and specific ci, etc, but if you do that, then you may end up with high number of sla definitions to maintain going forward maintenance are usually dictated by addition/removal/changes in your agreements with your customers and to reflect those changes, for every applicable sla, you may need to update the sla's conditions and/or its duration and /or its schedule when to use an sla using an example requirement to measure time taken to close an incident ticket, below are reasons why you may want to define an sla for the requirement you need to know if an incident closure is about to go over its agreed maximum duration, in real time, either via reporting or via notification you need to know if an incident closure is has gone over its agreed maximum duration, in real time, either via reporting or via notification you need to have visibility of the measurement on the incident process, including time measurements/clocks that are still running but has already breached their respective durations you need to be able to pause the timing calculation, e g temporarily pause the clock, when the ticket is waiting for the requestor to provide information the conditions (when the timing clock applies/pauses/stops) and/or the duration and/or schedule, require regular maintenance there is a legal/contractual commitment for the measurement you have process in place to enforce/perform ongoing reviews of the slas when not to use an sla using an example requirement to measure time taken from incident assignment to incident's assignee contacting the ticket's end user, below are the reasons why you may want to configure an alternative, i e measure and record the time taken, once into a duration type field you need to know how long the time was taken but not in real time, but after the fact i e the measurement can be calculated only when the end condition is met, e g incident's assignee contacting the ticket's end user you don't need to pause the time measurement along the way you don't need the complexity of having different conditions and variations of the timing nor you need any specific schedules there is no legal/contractual commitment for the measurement any delays / breach of the measurement are not enforceable but tracked for quality purposes instead sla definition configuration sla definitions for a given table can set up in a variety of different ways it should be noted that more than one sla can be run against a record at once sla definitions can be created and configured, minus the scripting fields, by the appropriate application administrators depending on the tables application that the sla definition is a part of an example of this is an itsm administrator can create and update sla definitions for the incident table field type example notes / description name string p3 incident resolve the name of a sla definition used to identify a sla definition table table incident the table that the sla definition will run its conditions off note that the table will need to have the appropriate triggers to have a sla start, which by default are any entities extended from work or interaction primary boolean true when a sla is flagged as a primary sla, it will be used to populate the sla status of an associated record where the field exists type choice response sla resolve sla resolve sla this field is used simply for reporting purposes to assist in filters or otherwise active boolean true this will determine if a sla definition can be run and can generate a sla record duration duration 16h the business duration (within the schedule) of time this sla will run it expects the duration with a number and then period of time (in lowercase) to designate the duration d day (24 hours), h hour, m minute and s second e g 4d 3m is the same as 4 days 3 minutes example, if a required sla duration is 3 5 business days and each business day duration is 8 hours, then you will need to set the sla's duration to be 28 hours (28h) after saving your change, the duration will appear as 1d 4h time zone choice list of timezones (gmt +10 00) canberra, melbourne, sydney this is the timezone when a sla will run (when a schedule has been selected) schedule reference \[schedule table] weekdays 9 to 5 with australian public holidays the schedule of the sla, which is the source of what hours are considered a business day, public holidays, etc note an empty schedule means the sla will run 24x7 to configure a schedule, please go to schedule threshold reference \[sla threshold table] standard this is a reference to a threshold table that determines at what percentage of an sla's duration will change its progress level to warning start time field field created on allows the sla to pull its start date/time from a field if not specified, the sla will calculate from the time it is triggered start condition condition builder priority is p3 | medium this is the condition when a sla will start it should be noted that the start condition needs to be true until the sla is stopped if it does not meet and the stop condition is not met, it will cancel the sla in situations where both the start condition and start condition script have been filled, both conditions will need to have been met start condition script script this is the condition when a sla will start it should be noted that the start condition needs to be true until the sla is stopped if the condition is scripted it requires an answer variable to be true or false within the script you have access to the current record it is executing on via "current" in situations where both the start condition and start condition script have been filled, both conditions will need to have been met pause condition condition builder current status is incident resolved or current status is incident awaiting external party or current status is incident awaiting client action this is the condition when a sla will pause in situations where both the pause condition and pause condition script have been filled, both conditions will need to have been met pause condition script script the condition that is required to pause a sla if the condition is scripted it requires an answer variable to be true or false within the script you have access to the current record it is executing on via "current" this is the condition when a sla will pause in situations where both the pause condition and pause condition script have been filled, both conditions will need to have been met stop condition condition builder current status is incident closed this is the condition when a sla will stop in situations where both the stop condition and stop condition script have been filled, both conditions will need to have been met once an sla has stopped, it will not restart if the start condition is met again, it will make a new sla record stop condition script script the condition that is required to stop a sla if the condition is scripted it requires an answer variable to be true or false within the script you have access to the current record it is executing on via "current" in situations where both the stop condition and stop condition script have been filled, both conditions will need to have been met once an sla has stopped, it will not restart if the start condition is met again, it will make a new sla record cancel condition condition builder this is the condition when a sla will cancel in situations where both the cancel condition and cancel condition script have been filled, both conditions will need to have been met cancel condition script script the condition that is required to cancel a sla if the condition is scripted it requires an answer variable to be true or false within the script you have access to the current record it is executing on via "current" in situations where both the cancel condition and cancel condition script have been filled, both conditions will need to have been met copy pause duration on cancellation boolean if true, will copy the pause duration from a cancelled sla in the same sla group if 'cancelation group' is set, the cancelled sla must have the same value present for its 'cancellation group' value if 'cancellation group' is not set, then the cancelled sla must be of the same 'type' cancellation group string priority see 'copy pause duration on cancellation' sla thresholds these allow you to provide different levels when a sla is considered at the warning stage this allows you to have a different threshold level for different sla definitions, depending when a sla is considered at a warning stage or not in doing so, this will allow you to trigger the appropriate notifications or otherwise based on the progress level changing these allow you to change the percentage of the various levels, to ensure that the progress level changes when you require it is recommended that only the warning percentage is updated to accomodate this as standard, the levels are as follows at the generation of an sla, the progress level is considered "normal" at 50 percent of the target duration, the progress level will change to "warning" at 100 percent of the target duration, the progress level will change to "breached" sla records field type example notes / description sla definition reference \[sla definition table] p3 incident resolve this is the sla definition that generated this sla was generated from parent generic reference inc0003498 this is the record that an sla is for and conditions are running against state choice running paused completed cancelled completed the current state of the sla the state will change as the conditions on the related sla definitions are met or unmet target duration duration 16h the amount of business time that this sla will run until it is considered breached progress level choice normal warning breached normal depending on the threshold entries associated to the sla definition, will determine what percentage it is until it reaches a certain progress levels sla met boolean true determines whether the sla went into a state of completed, prior to running over its target duration achievement percentage decimal 7 0 the percentage of the amount of business time has passed from the started at to the due at field this is only calculated at the time an sla is stopped active boolean false this determines whether or not an sla is still running as a general rule, completed and cancelled slas are not active, whilst running and paused slas are considered active business duration duration 1 hour, 3 minutes and 37 seconds the business duration that has occurred, within the bounds of the associated schedule this is only calculated at the time an sla is stopped elapsed duration duration 1 hour, 3 minutes and 37 seconds the elapsed duration that has occurred, which excludes the schedule this is only calculated at the time an sla is stopped stopped at date time wed, aug 28, 2019 03 35 43 pm this is the date and time when an sla has stopped this is when it would have hit the status of completed or cancelled due at date time fri, aug 30, 2019 02 32 03 pm the date and time that if the sla is not completed, cancelled or paused the sla will considered breached, unless the duration is changed in the meantime started at date time wed, aug 28, 2019 02 32 03 pm this is the date and time when a sla has started paused at date time wed, aug 28, 2019 03 35 40 pm this is the date and time when a sla has last paused in situations where a sla has paused multiple times, it will only track the last time it paused pause business duration duration 3 seconds the business duration that has occurred, within the bounds of the associated schedule where as a sla has paused pause elapsed duration duration 3 seconds the elapsed duration that has occurred, which excludes the schedule where as a sla has paused schedule reference \[schedule table] weekdays 9 to 5 with australian public holidays the schedule of the sla, which is the source of what hours are considered a business day, public holidays, etc note an empty schedule means the sla will run 24x7 refer here for schedule configuration time zone choice list of timezones (gmt +10 00) canberra, melbourne, sydney this is the timezone when a sla will run (when a schedule has been selected) how they work when a record has been updated, there are numerous things that are done in in sequence when there are active sla definitions against a record it is done in this order, to ensure that the status correctly reflects what the sla definition has set the process that occurs when a record has saved (and the appropriate trigger is in place) are it queries the list of active sla definitions against the record's table it queries the active sla records against the record that was updated for every sla definition it will then determine if the parent record has met the cancel condition and / or cancel condition script for any of them if it does, it will cancel the active sla record determine if the parent record has met the start condition and / or start condition script for any of them if it does, it will generate the appropriate sla record determine if there are any sla's that are currently paused, the assuming they no longer meet the pause condition, unpause them determine if there are any sla's that have met the stop condition and assuming any meet the stop condition, it will stop the appropriate sla's determine if there are any active sla's that no longer meet the start condition (but are not already inactive) and cancel them determine if any meet the pause condition that are currently running if there is, it will pause them then for the sla definition that is flagged as the primary sla (when it gets to that sla definition or / and if it exists), it will update the appropriate sla status field on the parent record please keep in mind that when viewing an sla record's, the information on timings such as due at and started at, just like any other date/time field on the platform, will be displayed in your user's timezone for example, if the current time is 9 30am gmt+10 and a ticket is created and the ticket resulted in an sla to start and that sla is defined on a gmt+10 timezone to run for 12 hours with daily start time of 9am and finish time of 5pm and your user account is on a gmt+8 timezone when viewed in the sla's local time, i e gmt+10 timezone, the above should result in the sla starting at 9 30am and due at 1 30pm the following day however, when your user account (in gmt+8 timezone, 2 hours earlier than gmt+10) views the ticket's sla, it will show that it started at 7 30am and is due at 11 30am the following day timezone definition every time an sla is applied, the sla engine determines which timezone to use in the hierarchy below