The Spring Wave of CRM2013 (SP1 for on premise customers) introduced ‘Service Level Agreements’. These ‘SLA’ records aimed to meet a very common requirement for service desks whereby they are contractually bound to respond to a case within an agreed timescale, and also to resolve a case by an agreed timescale. This often varies depending on the level of service a customer has paid for. CRM traditionally struggled with calculations involving dates and this led us here at Gap Consulting to produce the ‘Auto SLA Calculator’, a comparison of which I will go through later in the blog.
The SLA record contains ‘SLA Item’ records which contain instructions on which KPI value to update (namely the ‘First Response by’ and the ‘Resolve by’ as mentioned above) when to trigger, what to do when failed and what to do when a warning is needed (typically a set amount of time before the resolve by is met).
The main output of these SLA Items that was not previously achievable using workflow rules are date values which take into account the working hours. So, assuming a case is created at 4:30pm on a Friday afternoon, if the working days are Monday to Friday and the working hours are 9am to 5pm, the resulting date/time would be 9:30am the following Monday.
Although a step forward, the common scenario whereby a case would be put on hold for example if the resolution was awaiting a 3rd party, could not be met.
In CRM2015, this scenario is met by the introduction of the ability to pause and resume the case. This sounds simple but actually demands quite a change in the entity model and as a result, only newly created SLA records that are marked as ‘Enhanced’ will be able to do this.
In order to determine what causes a case to be ‘paused’ and so causing the countdown timers to stop and re-calculate when ‘un-paused’, a new system setting is available in the ‘Service’ tab which allows the multi-select of active status reasons (i.e. on-hold or you may have some custom statuses such as ‘with 3rd party’).
When in enhanced mode, the failure and warning times are written to a different record called the ‘SLA KPI Instance’ as opposed to fields on the case entity. A sub-grid can be seen in the Enhanced SLA Details tab when looking at the default case form;
You may also notice a second timer control is visible, for both ‘respond by’ and ‘resolve by’ KPI’s. Be aware, these two timer controls are looking at data held on the SLA KPI instance record not the case.
Another enhancement is the addition of ‘Success Actions’ to the SLA Item.
It is worth noting that ‘Standard’ SLA records are still available for backward compatibility and also if you prefer to store the failure and warning times on the case as opposed to the SLA KPI Instance entity. A valid reason for this would be you wish to sort cases by these two date fields and as we know, CRM doesn’t allow a view to be sorted by a field which isn’t native to that record.
Pro’s and Cons of Enhanced v Standard SLA Records
Enhanced can pause and resume, standard cannot.
Enhanced can invoke success actions, standard would need a supplementary workflow to do this (however note difficulties in updating cases after they are resolved!)
Enhanced enables multiple timer controls, standard only has the one which must be added to the case form by an administrator.
Standard stores failure and warning times on the case making charting and sorting case views by these values achievable.
Queue Item views cannot display enhanced SLA fields.
So do we still need Auto SLA Calculator?
The Auto SLA Calculator was developed to do two things and works as an extension of workflow;
1. Take an input date, an input ‘Auto SLA Definition’ (which specifies the days and hours to be counted as ‘working time’) and returns a date/time in the future.
2. Take a ‘start date’ and an ‘end date’ then return both the elapsed and ‘working time’ duration, minutes and hours.
Granted, point 1 does now have some functional overlap with the out of the box SLA functionality, however, it is not restricted to ONLY work on the case entity and you can update whatever date fields you like with the result. Because Auto SLA Calculator consists of a custom entity called the ‘Auto SLA Request’, it can be used anywhere and given any value within the workflow create step.
Point 2 is the big differentiator and actually can be used to supplement the new SLA functionality. Calculating the duration or number of minutes/hours between two dates and optionally taking in to account ‘working hours’ is vital in assessing the performance over time of the support team. What’s the average amount of time taken to respond to or resolve cases in the last X weeks or months?
With the Auto SLA Calculator, we can pass the case ‘created on’ and now we have the ‘Succeeded On’ date which is held on the new SLA KPI Instance record, we can use this as our 2nd date in order to work out the time taken to resolve the case!
As an added bonus, the new SLA KPI Instance record is customisable so we can add a duration field to it and update it with our workflow.
The below example shows a simple example of how we can leverage Auto SLA Calculator to work out the time taken (with working hours taken in to account) for a case to be resolved.
We start by creating an Auto SLA Request record, populate to with the required values, then add a wait condition to allow the plugin which is registered on create of the Auto SLA Request record to execute. We then progress to an update step where we can update the new SLA KPI Instance which has a relationship called ‘Resolve By KPI’.
The Auto SLA Request must have an Auto SLA Definition selected in order to determine the ‘working time’. Once this record is created, the fields in the ‘results’ section will be populated (Date result is populated only when a start date and number of days, hrs, mins are passed, else the business and elapsed fields are populated).
Finally, we can add a chart to the new SLA KPI Instance that uses our new ‘Duration’ field and averages it over a time period of your choice!
Conclusion and Take Away Points
The new SLA functionality enables pause & resume without the need for complex workflow or plugins.
Using the new SLA functionality stores warning and failure information in a separate entity which can impact reporting and view sorting.
For generating SLA dates on the case entity for ‘respond by’ and ‘resolve by’ fields and pause/resume is required, then go with the out of the box functionality instead of Auto SLA Calculator.
If SLA dates are needed on other entities or multiple additional fields need SLA values generating, the Auto SLA Calculator is the tool to use.
If you need to calculate durations/min/hrs both elapsed and ‘working time’ between two dates, then Auto SLA Calculator is still a valuable tool.