How to Configure SLA’s and KPI’s in Microsoft Dynamics 365 Service

Customer Service SLAs

A large component of the Customer Service Hub for Dynamics 365 are SLAs (Service Level Agreements) and KPIs (Key Performance Indicators). Configuring these in your environment can be a bit confusing for someone who has never worked with these in the past. Here, we will walk through the steps to configure an SLA with multiple KPIs in a new Dynamics 365 Customer Service environment.

First off, what is a Service Level Agreement? A Service Level Agreement is a defined (by an organization) level of service that is offered to clients/customers for various industries. An organization may provide simply one level of service, or multiple levels for clients with larger accounts or customers that are willing to pay more for a higher level of service.

Key Performance Indicators are used to define the SLA, whether that be a first response to the client when a Case is submitted or ensuring the resolution or a Case within a set amount of time. These are two examples that are used by many organizations, while custom KPIs can be configured to meet your business needs. The KPIs, which will be date/time fields in Dynamics, are referenced to create a countdown to when a customer request will be considered noncompliant.

Getting Started

Within Service Configuration Settings, ensure that ‘Disable SLAs’ is set to No. This should be set to No by default, but it is worth checking just to make sure it hasn’t been set to Yes by mistake:

Before configuring any SLAs or KPI, we need to define the working hours for the organization. The working hours will be used to ensure that the SLA timers/countdowns will not include time after normal business hours or holidays observed by the organization.

In the Customer Service Hub, navigate to the Service Management area. Select Holiday Schedule:

Create a new Holiday Schedule and add your organization’s observed holidays to the below sub grid:

*Note that the holiday schedule needs to be maintained year by year in order to ensure accurate SLA times.

Now that we have a holiday schedule created, we can move on to creating our Customer Service Schedule, which will reference our newly created holiday schedule:

Create a new Customer Service Schedule. Keep in mind you can have multiple Customer Service Schedules for different areas of your business. I named my new schedule ‘Working Hours’:

Here you can set the working hours for your business:

You’ll also update the Holiday Schedule to ‘Observe’ and select the Holiday Schedule we just created:

Next Steps

Now that we have our Customer Service and Holiday Schedules in place, we are ready to move on to creating our SLAs and SLA KPI. Our first step will be to create our SLA KPIs, which are referenced when configuring the SLA itself. SLA KPIs will be used to determine the entity, the KPI field, and when the KPI is applicable from (which field on the Case are we using to initiate the timer for the SLA).

In this example, we are going to use the out of box KPIs that already have fields created in the Customer Service Hub. You can create and reference additional KPI fields if so desired or needed for your organization.

Navigate to SLA KPIs in the Service Management area under Service Terms:

Create a new SLA KPI:

• Name: The name of the SLA KPI.
• Owner: The user creating the SLA is populated by default.
• Entity Name: Select the entity for which the KPI will be measured.
• KPI Field: Select the respective KPI field.
• Applicable From: Select a value based on which the warning and failure time will be measured

The above is an out-of-box example for a Resolve By SLA KPI. The Resolve By KPI field has already been created for us. If additional KPI Fields are needed, you can create additional Lookup fields on the Case to the SLA KPI Instance table. In this case, we want to begin the countdown as soon as the Case is created in Dynamics.

Now, once the record has been saved, you can specify the Pause Conditions for the SLA KPI. In our example, we want the Resolve By KPI to pause if the Status Reason of the Case is set to either On Hold or Waiting for Details:

*Note that when an SLA KPI Instance is paused and then resumed, the instance is cancelled and a new SLA KPI Instance is created.

Once you have configured the Pause Conditions, you will now activate the SLA KPI:

Create SLA

Now that we have the SLA KPI configured, we can move on to creating the actual SLA itself. Service Level Agreements are located under the same Service Terms sub area within the Service Management area:

Select ‘New’ in the top ribbon:

• Name: Enter a name for the SLA.
• Primary Entity: Select a value in the box.
• Description: Enter a description for the SLA.

Provide a Name and the Primary Entity for the SLA. Keeping in line with our working example, we’ll select Case as our Primary Entity.

Once the record is saved, the next step is to create our SLA Items. An SLA can have multiple SLA Items associated with it. The SLA Items will determine the Warning and Failure time based on the Created On field specified in our SLA KPI. For our example, we are going to create three different SLA Items for our SLA. We are going to define an SLA Item for each possible Priority a Case can be assigned and specify different Warn/Fail Durations for each.

First, we’ll create the SLA Item for High Priority Cases. Select New SLA Item above the SLA Items sub grid:

Name the SLA Item ‘High Priority Resolve By’, populate KPI with our ‘Resolve By’ KPI, and select ‘Working Hours’ for Business Hours. It is not required to use a Customer Service Schedule, but is recommended.

Applicable When determines the criteria a Case (or whichever entity you are creating the SLA for) needs to meet to in order for the SLA Item to be applied. We’ll use Priority Equals High for this example:

The Success Conditions are how we will define if the SLA Item as successful, pretty self-explanatory. Since this SLA Item is for Resolve By, the Success Condition will be when the Status of the Case is equal to Resolved:

We have already determined the Pause Configurations for the SLA KPI, but we also have the option to get more granular on the SLA Item if desired. We’ll leave the Override Criteria option here set to ‘No’:

The next step is to define the Warn and Fail Duration for our SLA Item. For High Priority Cases, we’ll leave these settings as the default:

At this point, we are now able to Save and Close the SLA Item and move on to the next one. We’ll create two more SLA Items, one for Normal Priority Cases and one for Low Priority Cases. Follow the above steps, adjusting the Applicable When and the Warn and Fail Duration, to create the SLA Items to appropriately align with the other Case Priorities.

With our SLA Items, we also have the option to perform certain actions (not required) when the SLA Item is successful, noncompliant, or nearing noncompliant.

Selecting ‘Configure Actions’ towards the bottom of the SLA Item form will open a new tab redirecting you to Power Automate. Here an out-of-box Flow is created for you where you can then specify what actions should take place depending on whether criteria are met:

With the automatically created Flow, we can specify what actions should occur such as sending an email, creating a Task, or updating a record:

• Is Nearing Non-Compliance: Will run when the warning time is reached for the SLA.
• Is Succeeded: Will run when the SLA succeeds.
• Is Non-compliant: Will run when the SLA fails.

Final Steps

Once you’ve completed the setup of your SLA Items, the next step is to set the SLA as the default (if you don’t plan to have multiple SLAs for the specified Entity) and Activate:

You’ve successfully created an SLA! Now, when a Case is created, the default SLA will be applied and depending on the Priority the appropriate SLA Item will populate on the associated SLA KPI Instance.

The out-of-box Case form should already have the SLA KPI Instances sub grid available. There are a few different options for displaying the SLA Timers on the form. The first option is to leave the sub grid as is, displaying a list of SLA KPI Instances on the Case:

The next option, using the same sub grid for SLA KPI Instances, is to add an SLA Timer Control:

The result will now display the SLA KPI Instances as timers on the Case form:

The final option for displaying the SLA KPI Instances on the Case is to utilize a Quick View Form for the instances with the Timer Control. The setup for this can be seen below:

Quick View Form Settings:

Quick View Form Setup:

The Resolve in field in inserted as a Timer:

The setup for the Timer control along with the end result can be seen below:

Now when the Case is marked as Resolved within the set amount of time, the Resolve in and Resolve By will display as Successful:

One last thing to keep in mind when working with SLAs is that if you are importing SLAs to an environment with a Solution and they already exist in the target environment, the SLAs will be deactivated after you import the solution. If you are activating the SLAs via the user interface, the only option is to activate them one at a time. The recommendation is to avoid reimporting SLAs unless they have changed and keeping them in their own solution.