SLAs. SLAs, SLAs - The simplicity and complexity of Service Level Agreements in #DYN365

Using SLA's with Cases

There are a number of features built into Microsoft Dynamics that support the configuration of an SLA associated with the Case Entity. When working with any of the features in Dynamics it is always a good idea to understand what the programming team has already created AND what the strengths, maturity and weaknesses of these features are. When it comes to SLA's and CASES there are layers on each.

Take for instance CASES. Cases are not just one simple entity, cases include both the case entity and the Case Resolution Entity. When a case is resolved, key information is captured in the case resolution entity. Each are interdependent. Additionally each offer SOME customization and SOME you can't change that. It is that "you can't change that" which generally trips people up.

SLA's also have layered complexity. An SLA has both FIRST RESPONSE and COMPLETION functionality. You will want to consider what rules you would like to use to indicate a first response and what rules you would like to consider for the completion. Technically these get applied as two separate line items within one SLA and when the system runs these line items they are two separate, but dependent system generated workflows.

I have tried configuring without using a first response and the system just doesn't like this configuration. At this time I always recommend a first response even if the first response doesn't mean much to the end user.

So to use SLA's with Cases

1) Setup your service Calendar

2) Setup your Holiday Calendar

3) Create your SLA and associate the calendars, Add your SLA Line items with both a First Response line item and a Final SLA Line Item.

Pretty Straight forward? Well not exactly for there are some tricks. The first trick is all about those working hours. The working hours in  the calendar can significantly impact the end date for your SLA. PowerObjects has a nice screen shot, by screen shot blog post on setting up the service calendar.  

Key items to consider.

• Are your users working in different time zones?
• Have your users configured their Personal Options?
• Will there be different working times on different days?
• Do you want to stick with the 24 hour clock? *most likely
• What time zones are using the results of the SLAs?
• Do you want your due date to be updated by the SLA?

The next item to consider is your holidays. You need to decide which holidays need to be applied to the Calendar used by the SLA and these need to be entered into the Holiday Calendar. If you have holidays from different countries a reconciliation will need to be decided upon or different SLAs for different countries.

One last trick on calendars: Both the Service Calendar and the Holiday Calendar do not deploy as part of your solutions so update your pre-deployment checklist to include creating these calendars before you deploy to any downstream environment.

3) SLA Line Items - SLA's do not like to stop on activity status = inactive and as such it is always better to find a different way to end your SLAs. On case they might be slightly happier, but on a number of different projects .. ending an SLA line item on activity status = inactive has tripped us up. Each SLA line item that is triggered against a case is reflected as a workflow on the case. The clauses that you defined based on trigger for success, warning and failure are converted in Wait and If conditions.

When it comes to out of the box configuration there are also decisions that need to be made around pausing an SLA. For instance if a CASE is put on HOLD, you can set system settings to pause the SLA. Take a look at Allan Mira's write up on how to pause an SLA on a case (again great screen shots and recreating screen shots seems a bit redundant) 

For more on using SLA's on CASE, here is a STEP by STEP by Vishal Grade.

Using SLA's with a Custom Entity

The Components that make up an SLA include

•  Customer Service Calendar – defines the business hours to be used in the SLA calculation. A business can have multiple calendars to support different SLAs i.e. 24x7, 9-5 business days, Customer specific calendars
• Entitlements – defines the agreed number of Cases or Time that has been contracted with the customer for support. Entitlements can only be associated to one SLA. An SLA can be associated to many Entitlements.
• Service Configuration – define which statuses place an SLA on hold (shortcut to System Settings). Note that the pause and resume statuses apply to all SLAs and thus are not SLA specific.
• Holiday Schedule – defines the dates that are considered holidays in a particular region. If you work in multiple regions then you may have multiple holiday schedules. Holiday schedules can be applied to the Customer Service Calendar to be observed.
• Service Agreements – define the rules that apply to the agreement, when a SLA is triggered, when and what should occur if the SLA is successful, non-compliant or nearing non compliancy. (thanks to MVP Stephan for summarizing these in his insiders guide to SLAs post which is another great read)

BUT when configuring SLA's to work on CUSTOM Entities there are a number of other steps that also need to be configured.

1) The Custom Entity must be enabled for SLAs  (there is a checkbox on the Entity to enable SLAs) "A few words of caution! SLA needs a committed relationship. Once you have selected that checkbox and saved, (by the power vested in you by Dynamics CRM and the position of a configurator) SLA cannot be disabled for the entity."

2) The Custom Entity must have a relationships established with the SLA Entities (such as the SLAKPIInstance Entity)

3) You must use Enhanced SLA's with Custom Entities that need SLAs

 To configure the relationships for your Custom Entity with SLAs you can follow the Microsoft Customer Engagement Team's step by step. I have summarized it below, but there is more on the full post such as setting up timers and some key things to remember so I recommend you jump on other to the post.

1. Enable the custom entity
2. In the same Customization window, expand the SLA KPI Instance entity.
3. Click 1: N Relationships.
4. Click the New 1-to-Many Relationship button.
5. Select custom <entity> in Related Entity dropdown. Here is a catch! As soon as you select custom entity in the Related Entity dropdown, the Name field gets auto populated to “new_ slakpiinstance_custom entity”. You can use it as it is, but you will face issues if you want to export the SLAs created in this org to an org that also has SLAs enabled for customentity. This is because while importing the SLAs, the system will attempt to create this relationship in the target org. Since there will be a relationship already existing in the target org, the import will fail. So it is strongly recommended to add a different name or change the name to a GUID (with underscores).
6. Fill the Display Name to your taste
7. Save and close

 

I have found that I still wish there was more documentation available on Microsoft Dynamics 365 SLAs. They are almost entire module unto themselves.

Happy SLA'ing!