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 true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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 true unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type unhandled content type 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