Tag Archives: programming

Service Level Agreements on Case Entity in MS CRM Dynamics 2016

The Case entity has the built in capability to use Service Level  Agreements (SLAs). Often SLAs are in place to contract a service delivery time for a customer, however we will be using it for a slightly different purpose in this example.

This tutorial assumes you have basic knowledge of the Case entity, sending Emails, and Workflows within Microsoft Dynamics CRM.

This step-by-step tutorial illustrates the following situation:

  • Upon receiving a project request, a Case is created and information is entered
  • Case is then then assigned to a user
  • If a Case has not been assigned for 5 days, send an email to a manager
  • The SLA will succeed when Case is assigned
  • The SLA will fail and send an email if Case has not been assigned within 5 Business Days


The first step is to ensure proper Business Hours are set up for the Organization

  1. Navigate to the Service Management area: Settings > Business > Service Management

  1. Navigate to Customer Service Schedule and choose “New”: Service Terms > Customer Service Schedule > New

    3. Name your new Customer Service Schedule and add a Description.
    4. Choose Work Hours and Days which correspond  to the company’s working hours and click Save and Close. For the sake of this example, I have chosen Monday – Friday, 6am to 5pm. If we do not add a Customer Service Schedule, the SLA would count Saturday and Sunday towards the countdown time, but we want to restrict it to only count work days.

The next step is to create and configure an SLA for a form

  1. Navigate to the main Case form in your Solution to ensure the SLA KPI fields you require are on the form. I have kept the default Applicable SLA(STANDARD) Section which includes “First Response By” and “Resolve By” under the Summary tab. Let’s choose a field to be our flag: we will change it when the record is assigned. Add “First Response SLA Status” to the form. Its default value is “In Progress”, and we can change it to “Succeeded” when the record is assigned.

  1. Create the SLA: You can create a new SLA through the Solution, or by navigating to Settings > Service Management > Service Level Agreements.

  1. Name your SLA and choose the entity – we are choosing the default Case entity, but as of CRM 2016, other entities can have SLAs enabled for them as well.

  1. Enter the details for the SLA such as Business Hours, the Type and Description. I chose Standard because we do not need the ability to Pause and Resume at this time, which an Enhanced SLA would allow us to do.  As well, this SLA will be “Applicable From” creation of the Case.
  2. Under SLA Details, click the ‘+’ to create a new SLA Item where we will configure our workflow logic.

  1. The Related Case Field is where you choose a Date/Time field which will show the “due date” or Failure date/time on the form. You can choose any Date/Time field, but I stuck with the default: First Response By.
  2. The “Applicable When” section defines when the SLA should activate. As we want it to be active on all cases, no matter the priority, we will leave it blank.

  1. The “Success Criteria” section defines what logic must be met for the SLA to succeed and stop counting down. In our case, we have added the extra field “First Response SLA Status” to the form. Let’s stop the SLA when the value of that field on the Case form equals Succeeded.

  1. To finish up our SLA Item, we need to set up a Warning or Failure action. In our case, we want to send an email to a manager if the case has not been assigned within 5 days. In other words, if “First Response SLA Status” is anything other than Succeeded, the SLA will Fail after 5 days and send the email.

Set “Failure after” to 5 days (the max in the drop down ends at 3 days, but you can manually edit this field) and Add Step “Send Email” under Failure Actions. Set the properties of your email to send whatever message you choose, and send to whomever makes the most sense. No Warning is needed for this example, but you could choose to have an action occur before the Failure date to warn the user.

The last step is to create a Workflow to set our flag when a Case is assigned

  1. Our SLA will succeed when the field “First Response SLA Status” equals “Succeeded”, so let’s create a workflow that sets the field when the Case is assigned.
  2. Navigate to Processes within the solution and choose “New”.  We’re going to create a Workflow(Category) for the Case(Entity). If you want the field to update automatically (Real-Time Workflow) and stop the SLA within seconds, uncheck the “Run this workflow in the background” box. I have left it checked as an Asynchronous Workflow will work fine for this example.

  1. We want this workflow to change the value of the field when the Case is assigned. In order to set the trigger, we can choose to “Start when:” Record is assigned.

  1. Now we can change the value on the form. Click “Add Step” and choose to “Update Record”. After selecting Case, click Set Properties to set the value.

  1. Let’s change the status to “Succeeded”.  Save and close.

  1. Don’t forget to publish your changes! As a last step, let’s change the “First Response SLA Status” to read-only on the Case form, so no one can manually change it to succeeded.

Go forth and test!

  1. Test out the SLA to make sure it stops and does not send an email after the record is assigned
  2. Test to ensure that an email is in fact sent when the SLA has failed
  3. Optional Steps:
    • Consider renaming the First Response SLA Status field to something more specific to the SLA, for example: “Assigned Status”
    • Another alternative is to create a new field as your flag, perhaps a Two-Option Set (Yes/No) called “Is Assigned?”