Service Level Agreement (SLAs) FAQsSummaryTable of Contents: What is SLATypes of SLAsWhat is response and resolution SLA in Service-nowHow do I create SLA agreementWhat is a retroactive start in SLAWhat is Retroactive pause time in SLAHow is SLA calculated in Service-nowHow to Monitor Service Level Agreements (SLAs)How to Repair SLAsService Level Agreement (SLA) breakdown definitionsTroubleshooting guide for Service Level Agreement ( SLA ) issuesService Level Agreements (SLAs) are not attached - why?In Item Designer, service level agreements are not evaluated correctly on a catalog task when the task is closedWhat is the difference between Actual elapsed time and Business elapsed time?Considerations about Pause in Service Level Agreement 1. What is SLA An SLA definition is used to create and progress SLAs, enabling you to use an SLA system for your organization's tasks. An SLA definition record defines the timings, conditions, workflows, and other information required to create and progress task SLAs. The SLA [contract_sla] table contains the definitions of SLAs, which determine when and how they track time on tasks. SLAs are defined by three sets of conditions: Start ConditionsPause ConditionsStop Conditions When the start conditions are met, the SLA begins timing towards the defined duration. When the pause conditions are met, the SLA pauses its timing. When the Stop conditions are met, the SLA stops timing and determines whether the SLA was Achieved or Breached. For example, the default Priority 1 resolution (8 hours) SLA Definition defines the Task SLAs to attach to incidents with a P1 - Critical priority specifies appropriate conditions for those Task SLAs and uses the default SLA workflow to create events such as to send a notification when an incident's Task SLA reaches 50% of its allotted time. 2. Types of SLAs SLA - service level agreementOLA - operational-level agreementUnderpinning Contract 3. What is response and resolution SLA in Service-now Response SLA means that the end-user has created a ticket he/she is supposed to be informed to whom his request has been assigned. Like for any incident created end-user to be informed within 30 minutes or 1 hour that his ticket has been assigned to someone. After a ticket has been assigned to a user now resolution time for that ticket starts and ends when the user resolved/closed the incident. 4. How do I create an SLA agreement You can create one or more Service Level Agreement (SLA) definitions and use them to create an SLA record. This SLA record enables you to use an SLA system for your organization's tasks. For more details to create SLAs please refer link. 5. What is a retroactive start in SLA To choose a date and time field from the task that provides the start time of the task SLA. Offers the date and time fields available on the task type that this SLA definition applies to. For example, if you select Retroactive start on a Priority 1 SLA definition and choose Created in the Set start to the field, then the SLA is attached with the start time is the date and time from the Created field on the incident. 6. What is Retroactive pause time in SLA Enables the calculation of retroactive pause time on the specific SLA definition. For example, if you select Retroactive start on a Priority 1 SLA definition and then select the Retroactive pause time check box, the SLAs that have enabled retroactive start can recover prior to the pause time. 7. How is SLA calculated in Service-now SLAs are calculated and assessed by a business rule and scheduled jobs that run in the background. The mechanisms that control SLA Workflow and SLA Automation are independent of each other. You may have a requirement to send out email notifications from the SLA Workflow displaying the current elapsed percentage of the SLA. However, this does not work because using percentage in notification only displays the most recently calculated value of the Task SLA. This results in inaccurate values sent out in email when using SLA calculated values in a Task SLA email notification. One solution is to specify elapsed percentage in SLA notifications by using notifications for each percentage level. For example, email notification for "75 percent SLA Warning" is created and a special event is used to trigger that notification. The event can be called "sla.warning.75". Another solution is hard-coding these email notifications to trigger at a specified duration percentage and configure the workflow linked to that SLA definition to send an email notification after waiting for an elapsed percentage. For more details please refer link 8. How to Monitor Service Level Agreements (SLAs) You can view the details for every task SLA record created for a task. In the task SLA record, you can view the task SLA details such as the stage the task SLA is in and if it has been breached. You can also view the target of the agreement being defined: None, Response or Resolution. Target is used for filtering, searching, and reporting purposes only. Note: This feature is available only in new instances starting with Jakarta or a later release. In addition, you can get an overview of the timings for the task SLA such as the actual and business elapsed time and percentage, and the actual and business time left in days and hours. 9. How to Repair SLAs SLA Administrators can repair SLA records to ensure SLA timing and duration information is accurate. Repair of SLAs is useful to determine accurate timing information if your system has SLA records that contain incorrect values. For example, you may need to repair SLA records as a result of: poorly defined schedulespoorly defined conditions on an SLA Definitionsome other system anomaly The repair function removes the SLA record, then recreates and recalculates it from the start, including recreating the workflow. The repair uses the history of the Task and if appropriate will also create new Task SLAs that did not previously exist. For example, a new Task SLA may be needed if a new SLA Definition has been added since an associated Incident was created or updated. 10. Service Level Agreement (SLA) breakdown definitions Using SLA breakdown, the service owner or service desk manager can see detailed task ownership and SLA duration-related data for any task SLA record associated with a task. This helps determine which teams and users are contributing to SLA compliance. SLA breakdown is configurable and typically should be configured for the more significant SLAs such as P1 and P2 resolution. By default, the system deletes SLA breakdown data that is more than one year old. This is performed by a new table cleanup job sla_breakdown_by_assignment. Table cleanup jobs are defined in the [sys_auto_flush] table. 11. Troubleshooting guide for Service Level Agreement ( SLA ) issues Please check the LINK for some troubleshooting steps for Service Level Agreement (SLA) issues. 12. Service Level Agreements (SLAs) are not attached - why? A task_sla record will not attach to a parent record (Incident, RITM, etc) if both the Start conditions and Stop conditions are true at the same time.To prevent this behavior from happening, the user can modify their Start and Stop conditions so that they are distinct, making it very unlikely for them to both be true simultaneously. 13. In Item Designer, service level agreements are not evaluated correctly on a catalog task when the task is closed The business rule Item Designer - Task Sequence Complete has a default order value of 100, so it runs before the Run SLAs business rule (order value of 101). You can correct the issue by changing the order of the Item Designer - Task Sequence Complete business rule to a value of 200. For Reference please go through the link: 14. What is the difference between Actual elapsed time and Business elapsed time? The SLA Engine maintains two sets of elapsed timings on each Task SLA record. The Actual fields contain times that are always calculated on a 24/7 basis. These fields indicate the physical time that has elapsed since the Task SLA record was created. The Business fields contain the timings based on the schedule that is associated with the Task SLA record. Schedules define a set of working or business hours. 15. Considerations about Pause in Service Level Agreements The Paused stage for a task_sla is only an indicator that the record is paused. The 2010 and 2011 SLA Engines consider a task_sla to be paused only if the pause_time field is not null. If the pause time was not recorded in the record, it is not really paused and will continue to be processed even if the stage says Paused. While a task_sla is paused, the planned_end_time does not have any meaning because the engine has stopped calculating it. Because the length of the pause is undefined, the planned_end_time can't be known. The SLA Engine leaves the value set to its last expected value and will recalculate the Planned end time when it comes off pause and resumes. As documented in "Example: Using Relative Durations with SLAS" in the product documentation page Define a Relative Duration, pause processing is not compatible with relative durations. This is the reason the Pause Condition is removed from the form when you specify a relative duration in an SLA Definition. Related LinksPlease refer product documentation for further details. https://docs.servicenow.com/csh?topicname=service-level-mgmt-landing-page.html&version=latest https://docs.servicenow.com/csh?topicname=c_ConfigureSLAs.html&version=latest