In my previous article about creating Dynamics 365 Service Level Agreements, I went through creating an SLA in the system. Now, I will explore Dynamics 365 Service Level Agreements Methodology and design and then review the SLA in Action.
For more information about setting Dynamics 365 Service Level Agreements Methodology, check the link.
What Do They Need?
Let us go through what the need for the SLA is for. The SLA is to ensure that a service request is completed in 15 mins. I am using such a short amount of time as it makes it easier to test.
We could easily make one for the 15 mins, but there are different stages during the lifecycle of the service request; for this example, there are three stages: Assigned, Resolved, and Verified. It would be great to know how long each of these stages is taking in case the total SLA is failing too many times, and knowing where the process is taking too long is key in modifying the process.
We are going to create a timer for each of these stages with two thresholds for each, the warning and failure. We will also create a final timer for the overall. Here are the details for each of these timers:
- Submit to Assign
- Warning after 3 mins
- Failure after 5 mins
- Assigned to Resolved
- Warning after 3 mins
- Failure after 5 mins
- Resolved to Verified
- Warning after 3 mins
- Failure after 5 mins
- Submit to Verified
- Warning after 3 mins
- Failure after 5 mins
Dynamics 365 Service Level Agreements Methodology
Explaining Dynamics 365 Service Level Agreements Methodology will require to review how the SLA evolve from on stage to another as follows.
Live in Action
Now let us see what the SLA we built in the first article looks like in action. Begin by creating a new case and populate the SLA field with the SLA we just created.
Once the form is save, it will look like this
Then, after adding a value to the Date Assigned, it will look like this
And when the Resolved On value is added, will look as below.
lastly, when we add the Verified On date.
As you can see as you move along the process and complete the stages the next SLA KPI kicks in using the date of completion of one stage as the starting date of the next stage.
One last thing to look at is the SLA KPI Instance. If we click on Submitted to Assigned we get to see the details of the instance.
Here is the information you can use during reporting. When an instance record is created it will populate the Failure Time and Warning Time using the thresholds created earlier. The Succeeded On is populated once the success condition is met.
What Does This All Mean?
Now that we have an SLA and it is running let’s go over some example to better understand the design concept. Here are three examples where one of the stage SLA’s were not met but the overall was.
| Assigned | Resolved | Verified | Total |
|---|---|---|---|
| 6 mins | 3 mins | 3 mins | 12 mins |
| 4 mins | 6 mins | 4 mins | 14 mins |
| 2 mins | 3 mins | 6 mins | 10 mins |
As you can see in each example, one of the SLA’s were not met, but, in the end, the total process succeeded in meeting the SLA. Because of how this was set up instead of having one SLA for the total time, we can see where the issues may be. Also, with this design, the notifications for the warning and failures help people stay on top of it before it was too late.
If we had waited to notify someone at 13 minutes that the SLA is about to fail, it might have been too late. Remember that each stage takes time to complete, so by having an SLA for each stage, we make sure that the next stage has its allotted time to be completed and not rush because a previous stage took some of their time.
Now you know how to build a Dynamics 365 Service Level Agreements Methodology, how to use it and what it all means. In my next article, we will review how to add actions to the SLA.
