Dynamics 365 Service Level Agreements Setup

Dynamics 365 Service Level Agreements allow case managers to setup criteria upon which to monitor and analyze the case response time across their organizations. These criteria can include things like first response and case resolution time.

A first response Service Level Agreement was setup at a client’s request to ensure that all cases are initially responded to within one business day. This Service Level Agreement monitors a Customer Service Rep’s initial response to a case.

Microsoft provides helpful documentation on setting up a Dynamics 365 Service Level Agreement. You can find that documentation here.

Issue with Email Warning NOT being delivered

Next, I proceeded to configure the Service Level Agreement.  Triggering a warning can be set for when a threshold is met.   In this instance, an email reminder is sent if the Customer Service Rep (CSR) assigned to the Case does not respond within four hours.  Note: The elapsed hours calculation automatically takes into consideration the Business Hours configured.

The other warning actions that can be configured are: Create record, Update record, Change status and Assign record.

I discovered that the email created in the Warning Actions part of the configuration was not being sent! After reviewing the configuration, I determined it was being done correctly and was not the source of the issue.

Dynamics 365 Service Level Agreements Workflow Discovered

The warning email was configured to be sent out if  four hours had elapsed and the first response had not been initiated. However, the email message was not being created.

While troubleshooting, I discovered an automatically generated background workflow running on the Case record that originated at the time of Case creation. This workflow was managing the Dynamics 365 Service Level Agreement processing that had been configured. Hence, the “First Response By” name of the workflow. I reviewed the workflow in order to determine what was preventing the warning email from being sent.

Please note: The workflow displayed below now includes an update to the case record. It initially was creating and sending an email to the Customer Service Rep. In order to facilitate creating charts and dashboards regarding the  SLA results,  I decided subsequently to include a custom field on the Case to house the SLA Status. This information is tracked on the SLA KPI Instance records that are attached to the case and NOT ON THE CASE ITSELF.  This is the reason for adding the custom status field.

When an SLA is applied to a case, one SLA KPI Instance record is created (for each SLA Item attached to the applied SLA) and attached to the case. The lookup fields configured in the SLA KPI related to the SLA will be populated with the newly created SLA KPI Instance records. The SLA KPI Instance records track information for each related SLA item: status, failure time, warning time and succeeded on time. 

First Response Workflow Dissected

The workflow is monitoring the state of the Case to determine if it has passed the service level agreement criteria that has been setup and updating the associated SLA KPI instance accordingly.

The first Wait Step is highlighted in the workflow shown below. This step is waiting until the First Response sent equals Yes, the Case Status is Cancelled or Resolved. In these instances, it sets the SLA KPI Status to Succeeded.

It will timeout when the computed warning time ( 4 hours past the created on date of the case)  is reached. At that time, the SLA KPI Instance will be updated with an “approaching non-compliance” status and update the case accordingly. The original configuration I had setup had an email being sent from the CSR manager. The issue was that the CSR manager user was not configured to allow users  to send emails in their behalf. As a result, the processing in the workflow stopped with an error and the email was never sent. It also never got to the second wait statement.

The second part of the workflow shown highlighted below is waiting again until the Case Status is Cancelled or Resolved. The SLA KPI Status is then set to “Succeeded”.

When the computed failure time (which in this case is one Business day )  is reached, it will timeout. The SLA KPI Instance will be updated with a “Non-compliant” status.

I hope this blog was informative and aids in any SLA troubleshooting you might need to do.