MB-230: Microsoft Dynamics 365 Customer Service – SLAs

I am currently revising for the MB-230 exam. This exam is for Microsoft Dynamics 365 and covers all aspects of customer service. As I revise I plan to publish blog posts that collectively will become a complete revision guide for anyone embarking on the same journey as me. In this post I will review service level agreements (SLAs).

Below you can see an extract from the current skills measured statement that mentions SLAs. In this post I will try and mention all of the topics referenced in this statement;

Note: If you have worked with earlier versions of Dynamics 365 you might need to be aware that the April 2020 release included an updated approach to SLAs. One which leverages Power Automate flow. Therefore a little extra revision maybe need here for some people!

What is an SLA?

A Service Level Agreement (SLA) is simply a way of defining and tracking what should happen when a case is created (Or changed). It reflects the agreement between the supplier and client and establishes expectations of service delivery times. For example: For a high priority case resolution must be completed within 8 working hours or first response for a low priority case must be completed within two days of receipt. SLAs act not only as the agreement between supplier and customer but also as a KPI for the supplier to monitor performance levels.

I am going to talk about SLAs in context of cases but you may need to be aware that we can apply them to other tables. (Such as leads or custom entities!)

The completion of an SLA and therefore performance against KPIs is achieved by a definition of success and failure conditions, plus (optionally) if a warning should be triggered as a failure state approaches. The actions that should be taken at each stage can be defined, for example sending an email to a line manager if a failure state is approached. (With the latest version of SLAs the actions to be completed are actually controls using a Power Automate Flow.)

SLAs might be based upon the type of customer, the agreement which is in place with the customer, or on attributes of a specific case. (Such as priority or channel.) The service level agreement may also be associated with an entitlement.

It is important to know that your ability to create an SLA is dependent on your security role. Not all users will be (or should be) able to design their own SLAs.

SLA Setup

You can maintain SLAs from within the customer service hub. In the service management area you will find options to main the SLA KPIs and SLA agreements.

The SLA KPIs are the metrics you want to use to manage your SLA. Commonly on cases we’d want to manage when first response has been completed and when the case has been resolved. I will explain how to define these metrics later soon!

You can also maintain entitlements from the service management area of the customer service hub. I have described entitlements in a previous post. I mention this as you might need to be aware that we can associate an SLA with an entitlement. This approach allows us to have specific SLAs for specific customers.

There are some additional SLA related settings you may need to tailor before creating your SLA. These include defining your companies holiday schedule, and one or more calendars. (These will be your customer service schedule.) Additionally you may need to review the service configuration settings as some define how the SLAs operate.

Service Configuration Settings

Using the service configuration settings option you can access the system settings that influence the behavior of SLAs and entitlements. In particular you will need to decide which cases status values should pause the SLA timer. In my example I have selected to pause the SLA if the case is waiting for details. Therefore if set to “On Hold” or “Researching” then the clock will continue to tick.

Configure one or more calendars

You configure your normal working patterns using the “customer service schedule” option. Below you can see an example of a basic Monday to Friday 9am to 5pm calendar. You might need to define several calendars. For example, your standard SLA might run Monday to Friday 9am to 5pm but selected customers might have an enhanced SLA which works on a 24/7 basis. You’ll need to define each of your required working patterns ready to apply to appropriate SLAs.

Notice below how I have said “observe” holidays. This means any non-working time defined in our holiday schedule will impact the SLA. So next I’ll look at holiday patterns.

Define Holiday Schedule

Using the holiday schedule option I have created an example holiday schedule. Notice that in the grey ribbon bar you can see the year.

Note: One limitation here is that holiday shutdowns are always whole days. Part days are not possible using this option.

Again you might need several holiday schedules. For example: maybe one area of the business provides support on Christmas Day, whilst most people take this as a holiday.

First I create a holiday schedule … as shown below.

Now I can create my shutdown dates for each year. (Notice the year is shown in the grey bar!)

Define SLA KPIs
The next setup step is to define my SLA KPIs.

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 SLA KPIs looked like this.

Create an SLA

Having correctly configured our calendars and other options we are ready to create an SLA.

In real-world scenarios the definition of an SLA can be quite complex. As often companies will have multiple scenarios to reflect. Additionally the actions required when an SLA reaches a fail or warning state can vary quite significantly. In the notes below I will show just one example of how an SLA might operate ….. please keep in mind that many other variations maybe required. I encourage you to setup multiple differing SLAs as part of your revision.

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 you could have SLAs defined in the older style classic web interface and / or SLAs from the newer Unified Interface. As the old style SLAs are really now a legacy concept, I will concentrate on the latest version!

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.

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!

Amend 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 Cloud Flow.

First of all you will click “continue” to connect this Power Automate with your Dataverse. Your Power Automate will then look something 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!

The actions that you decide to add into your Power Automate Flow could do many things! Common examples would be to send an email to alert the case owner that the SLA was about to expire or had failed. For the purpose of this post I will have a simple example that just updates a field on the case.

In my simple example I want to update a field on 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. (Note: This is a custom field I created, your SLA will no doubt have different steps to mine. This is just an example!)

Once I save this Power Automate, my cloud flow will be added into my default solution. You might need to be aware of this as you’ll probably need to add the Power Automate into your own solution, assuming you need to migrate them from say a dev instance into production.

Using the SLA
After I had created all of my SLA items and their associated Power Automates (aka Cloud Flows) I am ready to activate / test my SLA.

Keep in mind that this is a simple example! I have only two SLA items listed in the SLA Details section. It might be that each priority / type of case has a different first response and resolution timescale. Therefore, I hope you can see that SLAs could get quite complicated!

So first you need to activate my SLA and also then set it as default.

SLA’s can be applied to a case in one of three ways;

  • When the SLA is the default SLA all new cases will have that SAL applied.
  • When the user manually assigns the SLA on the case. Using an SLA lookup column we can add to the case form.
  • By virtue of associating the case with an entitlement that is linked to an SLA.

I created a case and you can see that initially I have 2 hours to complete my first response.

On the SLA tab you can see the details for my first response and resolve by KPIs.

If my SLA conditions are met the status will change to succeeded, below you can see that I have sent my first response!

Alternatively if you do not complete the SLA in time you will see the status change into a warn and eventually fail state. Before you can see that I have a “SLA warning” as my SLA is nearing expiry.

I mentioned earlier that you could pause an SLA. Below you can see that my case has been set to waiting details. Doing this has paused the SLA timer. Setting the status back to “In Progress” would restart the timer, With the target failure / warning times adjusted to allow for the length of time the SLA was paused.

Hopefully this post will have given you a good overview of the capabilities of service level agreements. As part of your preparation for the MB 230 exam I encourage you to gain some hands on experience of using SLAs.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s