Dynamics 365 Customer Service SLAs and Cloud Flows

Within Dynamics 365 we can use SLAs in the customer service app. Each SLA item can trigger a Power Automate Cloud Flow to complete any actions we wish to implement when a warning, failure, or success status is reached. This is great but I’ve found maintaining the Flows can become cumbersome. In this post I will explain an alternative approach.

The Problem

Each SLA can have multiple SLA items. Typically I’ve created SLAs with two SLA items for each priority. Giving me SLA KPIs for first response and resolve by. Meaning I’d commonly have at least six SLA items in total.

The result is I would often have six cloud flows to maintain. Within each of those flows I’ll need to define actions to run as the SLA nears non-compliance, is non-compliant or succeeds.

Maintaining these six flows can be a slight pain. But now imagine that you don’t have one definition of your service level agreement. Maybe you have tens or even hundreds of slightly different SLAs. Recently I worked with a customer whose contractual SLAs were based on the opening times of their customers. Meaning potentially a slightly different SLA might be created for every customer. Suddenly you could have hundreds of Flows to maintain.

In my experience the actions we would trigger in all these Flows might be the same. In my simple example, I just wanted to update a “RAG” field on the case. In other examples you might want to always send an email to the case owner when the SLA becomes non-compliant. Or maybe you want to route all cases outside of their SLA to a particular queue.

The Challenges

Instead of having hundreds of Cloud Flows I wanted to create just one Flow that will trigger a common set of actions whenever an SLA status changes.

Initially I thought this was easy! But my single flow might need to complete different actions depending on the type of SLA. As it could be a first response or resolve by KPI. (Actually, it could even be for additional custom KPIs.)

And I could (in theory) have SLAs on multiple different tables. Often we “just” use SLAs for cases but we can create an SLA for other entities. For example, maybe you’d also have an SLA for work orders.

So, any Cloud Flow I created needed to be adaptable to multiple KPIs and potentially multiple tables.

In the end I managed to create a single Flow which worked and could be extended if I added additional entities or KPIs later.

My Solution

In the remainder of this post, I will explain the Cloud Flow I created.

My Flow is triggered when an instance of an SLA is modified. Meaning, if the status of an SLA against a case changes my flow is run.

When the flow runs, I read the associated SLA item. And the SLA KPI associated with that item. I also query the record the SLA is regarding. (Aka the case.)

Once I have all this information, I simply require a switch statement (condition) based on the SLA status and then another based on my KPI field. I can then insert any actions needed when the SLA reaches a particular state. (e.g. When my first response SLA hits the “nearing noncompliance” state.)

I admit my Power Automate is slightly more complex than the out of the box Cloud Flows which are partially generated for us whilst maintaining SLAs. But which would you rather do …. create and test one slightly more complex Flow or maintain several hundred???

I say this is more complicated …. it wasn’t really that hard! I basically query a few records and then have three nested switches. My overall (high level) Flow is shown below.

I will breakdown each step in more detail in the following notes.

The steps in my flow are …

1. The trigger (on the SLA KPI instance being modified.)
   
2. Query the SLA Item
   
3. Query the SLA KPI
   
4. Switch on entity
   
5. Read case
   
6. Switch on status
   
7. Switch on KPI Field and add actions
   

Step One – The trigger

Every automated Cloud Flow needs a trigger. Mine is the dataverse trigger whenever a record is modified, added or deleted.

I set my change type to “added or modified”. I suspect just modified might have generally worked. But I decided to included added just in case an SLA could be created that was already breached on create!

The table name is “SLA KPI Instances”. Whenever we create a case (or other record type), if an SLA is applied we will get a row created for each SLA KPI to be monitored for that case.

Also notice that my scope is “Organization” as all records will be subjected to this logic. Not just ones I own or ones in a particular business unit.

Step Two – Query the SLA Item

Each instance of a KPI is going to relate to a particular SLA item. So next I read the SLA item as that will give me the definition of this SLA.

So, I added a “get row by ID” Dataverse action. My table name is “SLA Items” and the row ID is “SLAItem (Value)”. Meaning the GUID of my SLA item which came from my SLA KPI instance that triggered this Flow.

Step Three – Query the SLA KPI

Knowing the SLA item, I now need to work out which KPI the item relates to. Is this a first response KPI or a resolve by KPI. (Or even a custom one as you could create additional SLA KPIs.)

So again, I used the Dataverse action to get a row by ID. But his time my table is “SLA KPIs” and the row ID is the “SLA KPI (Value)” which will have been returned by the previous get on SLA items.

Step Four – Switch on entity

In my system I currently only have an SLA for cases. But as already mentioned I could (in theory) create an SLA for different entities. And based on the entity I would probably need to complete different actions. So next I added a switch based on the entity.

My switch is on a field called “Entity” which has come from the SLA KPI we read in the previous step. This field will contain the schema name of the table that the KPI relates to.

As “cases” are known as incidents in the schema. My switch statement looks for a value of “incident”.

You might notice that I have added just one option to this switch statement. This is because I only have an SLA defined on incidents at the moment.

I guess I could have made my Flow slightly simpler by skipping this switch statement and just assuming all KPIs will be for cases. But I preferred this approach as I my Power Automate wouldn’t fail if I happened to create a new type of SLA. Also, I could hopefully easily extend this in the future.

Within my switch for incident, I would then include actions to read the case and also trigger another switch based on the status of the SLA.

Step Five – Read case

Now I know my SLA relates to cases, I can read the details of the case that the SLA is regarding.

So next I added an action to get a row by ID. My table name is “Cases” and the row ID is the regarding ID from my SLA KPI instance.

Step Six – Switch on status

And now we have another switch! This time I want a switch based on the status of my “SLA SKPI Instance”. In my example I might want to run actions as the SLA is nearing non-compliance, is non-compliant or has succeeded.

Each of the status choices has a value ….

• Nearing noncompliance = 2
• Noncompliant = 1
• Success = 4

Tip:
Other status values exist, which I didn’t need to implement but you could! Inprogress (0), Paused (3) and Canceled (5).

Below you can see my switch based on status.

Each switch will be looking for a value. So 2 for nearing noncompliance, 1 for noncompliant and 4 for success.

Step Seven– Switch on KPI Field and add actions

Finally, I can add any actions I want to trigger when my SLA reaches this state. In my simple example I am just updating a RAG field on my case. As the RAG field gave a simple way for me to see a red, amber or green indicator on the case. In your Flows you might want to add actions that perform different steps. For example, you could trigger an email to the case owner.

Below you can see the switch and actions I added below.

The switch is to allow me to have different actions based on this being a “first response by” SLA or a “Resolve by” SLA. Essentially the idea here is to have a switch based on the lookup field that relates the SLA KPI. You will find a field called “KPI Field” on the “SLA KPI” table. Meaning a different lookup is used depending on the KPI type selected.

Out of the box on cases we have two lookups to SLAs. “firstresponsebyid” and “resolvebykpiid”. It is possible that you are working with another entity or maybe you have extra SLA KPIs to a case. If so you’d need to identify and enter the names of your custom lookups.

Above I showed the logic I’d created for “Nearing noncompliance”. Below I have shown the switches / actions I created for being “Noncompliant”. As you can see the approach is pretty much identical for both. It is just that I might need to trigger different actions on each. In my example I update the case RAG to amber when I am nearing noncompliance. But I change it to red when the noncompliant status is reached.

And that is it! Simples!! I agree there are quite a few steps but each one is simple. I hope you can appreciate the idea here and how by following this approach we can significantly reduce the number of Flows to maintain for SLAs. Enjoy!