SLA’s in the Unified Interface

Posted by: Dian Taylor | on May 5, 2020

Some people might not have noticed that SLA’s (service level agreements) didn’t just move from the legacy interface to the unified interface. There were also a few updates to SLA’s and the way we can configure them in Dynamics 365 Customer Service has slightly changed. Before I get into that, let me first explain what SLA’s are and how they are used.

What are SLA’s?

Service level agreements allow organizations to define the level of service they offer to their customers. For example, an organization might want cases for gold level customers to get resolved in 1 day, while silver level customers are promised a resolution within 2 days. SLA’s in Dynamics 365 are used to keep track of these rules and we can configure actions (I.E status updates and notifications/warnings) that will happen when a case is close to nearing non-compliance or becoming non-compliant all together. SLA’s can be used with several different entities, but in this example I am going to focus on using them with cases. Once the SLA is created, configured and activated, we can attach it to a case. This can be done manually or automatically. (We can have the system automatically attach the default SLA to every new case or use entitlements. Keep in mind only SLA’s for the case entity can be associated with entitlement records.) The other thing to keep in mind is that multiple SLA’s can be triggered for a record, at different starting points. I.E. Maybe all incoming cases go to a queue. There could be an SLA for all new cases to be assigned to an customer service rep within a set time frame, once the csr is assigned another SLA can keep track of how quick the case is resolved, etc.

SLA KPI’s

Before you can start creating new SLA’s, you will first need to create SLA KPI’s. SLA KPI’s are key performance indicators which hold information about the entity it’s related to, the field the SLA uses to trigger the SLA, and the SLA KPI field, which is a N:1 relationship between the entity selected in the entity name field and the SLA KPI Instance entity. In the screenshot below the case entity is selected in the entity name field, and the SLA KPI field represents the N:1 relationship between the case (incident) entity and the SLA KPI Instance entity which is the lookup field on the case entity called ‘resolvebykpiid’. There are two out of the box lookup fields we can use for this on the case entity: ‘First Response by KPI(firstresponsebykpiid)’ and ‘Resolve By KPI(resolvebykpiid)’, but you can create your own by adding another lookup field to the SLA KPI Instance entity.
To create SLA KPI records you will need to navigate to the Service Management Area and select SLA KPI’s under Service Terms. Click the +New button and enter a name for the SLA KPI and select the entity the SLA KPI will be related to. Since I’m using cases in this example, I’ll create 2 case KPI’s, the First Response KPI which will track the time a first response message has been sent to the customer and the Resolve By KPI which tracks when a case should be resolved. The ‘applicable from’ field represents a date/time field the system will use to trigger the SLA and to calculate how much time has passed. We will use these KPI’s when we create the SLA items. Once the SLA KPI’s are created you’ll need to activate them.

SLA

In order to create a new SLA click on Service Level Agreements (above SLA KPI’s) and click the +New button. Enter the name of the SLA and select the primary entity. (I.E If you haven’t created and activated any SLA KPI records, the field will be blank) Keep in mind that the SLA itself is more of a container, the actual rules are configured in the SLA Items.

SLA Items

When adding an SLA item, there are several fields you need to populate: the name of the SLA Item, the KPI (1)(this is where you link the SLA KPI’s that we created earlier. Keep in mind the SLA KPI holds the ‘trigger’ field that is used to calculate the time that has passed. Once the SLA is triggered, it will then look at the conditions that are configured under the ‘Applicable When'(2) section. If this rule only applies for ‘gold’ customers, this is where you would configure that logic. The ‘Success Conditions’ (3)are what determine if the condition has been met. I.E For a case resolution rule the success condition is most likely going to be when the status of the related case equals resolved or cancelled. The warn(4) and fail(5) duration is where we set how much time passes before the case is nearing non-complicance (warn) and how much time passes before the case is considered non-compliant (failure). The values in these fields are used to calculate the failure and warning times for each case the SLA is attached to.
In the business hours field (6), you can select a customer service schedule that holds the hours of operation. If you select a customer service schedule the system will include this in the calculations. (I.E. The customer service work schedule is set from 8AM-12PM and 1PM-5PM . If a case has an SLA attached with an SLA Item that requires the case to be resolved within 8 working hours, and the SLA triggers on Monday at 3PM, the customer service rep will need to have this case completed by Tuesday 3PM(failure time). If there is no customer service schedule selected on the SLA the case needs to be completed by 11PM that same Monday)

The last thing we need to configure are the actions (7). These are the things we want to happen when certain criteria/conditions are met. If we use the screenshots in this article as the example, we’re using the ‘Follow Up By’ field in the SLA KPI as the ‘Applicable From’ field. (This is both the trigger field and the date field we’re going to use to calculate our warn and failure times) We have a warn duration of 6 hours which means the if the success condition is not met after 6 hours, the case is considered ‘nearing non-complicance’.
We have a failure duration of 8 hours which means the if the success condition is not met after 8 hours, the related case is considered ‘non-complicant’. The success condition is met when the case status equals resolved or cancelled.
When you click on the actions button(7), the powerautomate screen will load. Click on ‘continue’ to start configuring the flow. Most of the flow has already been created, we just need to configure what needs to happen when the case meets the success condition, when it nears non-compliance(warning time) or when it’s non-compliant(failure). Click on ‘[Do not delete or update] Switch’ to show each condition. Click on any of the conditions to expland. Under each condition you can click ‘Add an action’ to start configuring the logic for when this condition is met. For example when configuring the ‘Is Near Non Compliance’ we can set the ‘Resolve by SLA Status’ field on the case to ‘Nearing Noncompliance’ so we can see cases with this status in a chart. A second step could be to send an email to the case owner or their manager, warning them that the case needs attention.

SLA KPI Instance Records

Ok, now we understand the logic, but lets talk about what actually happens in the system when an SLA is applied to a case. Once a case is applied it needs to be triggered first for things to start happening. Once it’s triggered, one SLA KPI Instance record is created (for each SLA Item attached to the applied SLA) and attached it to the case. The lookup fields configured in the SLA KPI related to the SLA will be populated with the newly created SLA KPI Instance records. The SLA KPI Instance records track information for each related SLA item: status, failure time, warning time and succeeded on time. It’s important to understand this information is tracked on the SLA KPI Instance records that are attached to the case and NOT ON THE CASE ITSELF. The SLA KPI Instance records can be viewed on the Enhanced SLA details tab on the case form and because the lookup fields are populated with the SLA KPI Instance records, we can pull related data in a view and on a case form!

Below is a video where discuss the different components of SLA’s. I also show how to create and configure an SLA and I walk through different scenarios.