The April 2020 release wave of Dynamics 365 includes an updated approach to SLAs. In this post I will explore how to create the “new style” Service level agreements.
Assuming you have some experience with Dynamics 365 …. I guess you will already be aware that we are moving away from the classic web interface and that eventually all functionality will be only available in the new unified interface.
Previously we could only maintain SLAs within the classic web interface. I believe we could view them in the Unified Interface Version of the Customer Service hub but we couldn’t edit them. The April release includes the ability to maintain SLAs directly in the Unified Interface. That is great but actually April wave includes much more!!
With an SLA we have always been able to define warn, failure and success actions. This has relied on a “workflow style” capability which allowed us to update records, send emails and more when an SLA was breached. The updated version of SLAs provides all of the same capabilities but delivers this using Power Automate (aka Flow). Meaning we have much greater capabilities than previously available.
In this post I will explain how I created an example SLA using the April wave approach ….
In my simple example I will have a two stage SLA. With “first response by” and “resolve by” SLA KPIs. Both of these SLAs will be based on the date the case is created. And will differ depending on priority.
The steps I take when an SLA is breached will be really simple! I want a custom RAG status field on my case which I will simply update to give a simple visual alert to users. Obviously I could have many more steps than this in a real scenario. As other typical actions might include wanting to change the ownership on the case, move it to a different queue or maybe sending an email to the manager of the case owner. (Hopefully you can appreciate that and expand this example to achieve these things and much more!)
The steps involved in creating my example included;
- Create custom fields and add them to my case form
- Define my SLA KPIs
- Define my SLA
- Amend Power Automate to update my custom fields
Step One – Create custom fields
I needed two “RAG” fields on my case. One for the first response SLA and one for resolve by SLA. This was simple enough, you can see an example of one of my RAG fields below. See how I added an emoji into the optionset values. (I like this as it gives a clear visual prompt to users.)
Once I’d added my option sets to my case form I ended up with something that looked like this … “yes in my test data the Hulk does start off green and eventually turns red!”
FYI: Just to be clear … I am not presenting the use of these RAG optionsets as being a great real world idea!! I have created these fields simply as an example. I am using them to confirm that my Power Automate has triggered at the right times as it will update the values. In a real example your “flow” would perform different steps!
Step Two – Define my SLA KPIs
The next step is to define my SLA KPIs, as none exist out of the box.
SLAs can be applied to entities other than case but obviously I’m going to stick with case for this example. I’m going to want two KPIs. One SLA will be measured against first response, so how fast do I acknowledge a customer’s query. And the next will be based on resolution, so how fast do I fix the issue.
Below you can see that I’ve opened the service management area within my customer service hub. I have then opened the “SLA KPIs” option. Within this option initially I have no active KPIs.
Tip:
Don’t forget after you create your KPIs they must be activated to be ready for use!
I created two SLA KPIs and activated them. One for first response and one for resolution. Below you can see that I’ve given my KPI a name. I then select the entity this KPI applies to, when it applies (SLA KPI) and based on what date.
The applicable from date is often quite important. In my example I want the SLA to start from the date the case is created. That will be quite common. But what is the priority on my case changes? In my example the SLA is going to be recalculated from the date the case was created, that might be fine. But in some scenarios you might want to use the date the case was modified or maybe even a custom field.
Tip: In real world scenarios I have often used a custom date field. As the case created date is when your customer service advisory originally clicked save on the case. Yet your SLA might actually need to start from the time a customer sent an email, which depending on your business processes and levels of automation could be much earlier than the case creation date. So having a custom date field that can be set to a time prior to the created date on the case can be a benefit.
Having added and activated my two KPIs my view of active SLAKPIs looked like this.
Step Three – Define my SLA
Next I needed to define my actual SLA. Obviously I could have multiple SLAs that are applied in different circumstances. Maybe customers who get my “bronze” level of service have a completely different SLA to my “Platinum VIP” customers! But in this example I will keep things simple and define just one default SLA.
In the service management area of my customer service hub I can maintain service level agreements. (Shown below.)
Importantly notice that the default view of “All Service Level Agreements from Unified Interface”. This is because (as mentioned) the SLAs created in the new UI are different.
Tip: You can change the view to “All Service Level Agreements”, this will allow you to see SLAs created with the classic interface. But you cannot edit those “legacy” SLAs with reverting to the classic interface. (The reverse is also true, as in the older classic web interface you can see the new style SLAs but cant amend them.)
When I create a new SLA, I first enter a name for my SLA, select an entity and optionally add a description. If you have multiple SLAs the description might be really useful to be able to understand the purpose of this particular SLA. Once the SLA is saved you will be ready to add your SLA Items.
As I add my SLA items I give each one a name. I also select which KPI the SLA item is based on.
The allow pause and resume lets me optionally decide if this SLA will pause. I might, for example, want to pause my SLA if the case is put on hold because I am waiting for information from my customer. I define which status will pause SLA in the system configuration settings. (See note at the end of this section!)
Importantly I next select my business hours. If I don’t my SLA will apply 24/7 365 days per year. But If I want my SLA to follow my normal working week and to take business closures into account then I’ll need to define / select a calendar.
Next I will select when this SLA is applicable. In my example I have decided to have two SLAs. One for cases of normal priority and a shorter one for cases of a high priority. (Low priority cases will have no SLA!)
I also define the success condition. For “first response by” success might be that the field “first response sent” has been set to yes. For my “resolve by” SLA, then success might be that the case status has been changed to “Resolved”. (and maybe “Cancelled” as I’d also stop the SLA if the case was cancelled!)
You can see that I then define my warn and failure times. I might for example, have 8 hours to give first response on a normal case. But maybe only 2 hours on a high priority case.
Note: You may notice that the actions section doesn’t show! Actually after I save the SLA item I will get a configure actions button. That will allow me to maintain my Power Automate. (More on that in second!)
You can see below that I defined four SLA items. Two for first response and two for resolve by.
Note: A note here about my warn and failure times might be useful! They are easy to visualise if you work 24/7. As one day would literally mean I just resolve the case by tomorrow. What if I only work 8 hours per day and “just” 5 days per week. Then 24 hours (aka 1 day) would mean I have 3 working days to resolve the case.
Tip:
I like to think of my SLAs always in terms of the number of working hours I’m allowed to complete the task. If you always enter them as hours the system will convert to days (and fractions of days) automatically.
Note:
Below you can see that in the service configuration option. In this I can define which case status values will pause my SLA. Along with some other SLA related system settings!
Step Four – Amend Power Automate
So far the screens have differed from the classic web client version of maintaining SLAs but the overall logic has been pretty much identical. Now we come to the biggest difference! As defining the actions will involve working with Power Automate.
On each of my SLA items I have a “Configure Actions” button.
Clicking the configure actions button will open Power Automate and drop me into a template flow.
First of all you will click “continue” to connect this Power Automate with your common data service. Your Power Automate will then look like mine below.
Importantly, notice that some elements of the Power Automate include “Do not delete or update” in their description. Guess what, you don’t edit these bits!
But you can expand the switch condition by clicking on it and then start to add actions for each status. (Below you can see that I have options for near noncompliance (aka warn), succeeded and non-compliance.)
Tip: The switch condition also includes a default option. This might be useful as would be triggered when a case is first created. You could additionally add actions to that!
In my simple example I want to update the case to amber on warn and red on failure. So I have added an update record step. This is connected to my current environment, the entity is cases and the record identified has a dynamic value of “Regarding ID”. This is the ID of the record connected to this SLA instance, so in my example my case.
I have then scrolled down and set the desired field on my case. So for me that means my RAG field.
Once I save this Power Automate it will be added into my default solution. As shown below;
Tip: I haven’t (yet) tested moving a new style SLA from one instance to another! But the fact the Power Automates get created within my default solution will hopefully be very useful. As I could add them into my own solution as required!
TESTING
After I had created all of my SLA items and their associated Power Automates I was ready to test my SLA.
First you need to activate it and also then set it as default. This is the same process as with SLAs created in the classic web interface.
I created a case and you can see that initially I have 2 hours to complete my first response. And my custom RAG field is green.
After a couple of hours my Power Automate kicked in and (as expected) my status changed to amber.
In conclusion, what do I think of these new style SLAs??? I really like the concept of them being based on Power Automate. Although if I’m honest I found the process of amending the Power Automates to be a little harder than adding actions in the classic web interface. But I consider that an acceptable trade off, the flexibility of Power Automate more than makes up for this extra effort!
In short I think the new SLAs are amazing and I hope you really enjoy working with them.
Final Tip:
You will also find that record creation rules are evolving to use Power Automate. I might blog about those one day soon!
NEIL PARKHURST 
Leave a comment