¡Hola, amigos! Our good friend Pablo “CRMGamified” Peralta continues about all SLA things he started in la primera parte.

¿How is the SLA applied?

We will see an “SLA Details” section where we can set SLA Items, each of their conditions, associated KPIs, and Alert or Failure actions to take whether set service levels are met or not. For instance:


This item is set to apply a 10-day tolerance SLA with a warning sent 3 days after certain conditions are met. An email will be sent when a deadline (failure or warning).

Take the following into account:

• The first SLA Item that fulfills the specified conditions for a KPI in “Applicable when” will be the only one set off for that KPI from all the SLA Items within the “SLA Details” section. No other SLA Item will be set triggered, even if it could also potentially fulfill all conditions.
• Therefore: pay close attention to the order in which you create / place SLA Items, making sure you clearly specify the conditions to trigger the correct Item. For instance, verify client type (VIP client, Premium client, standard client, etc.) as the first condition:
  
• Avoid including fields that significantly vary in the conditions, since this would force the system to constantly re-evaluate them, potentially impacting performance.
• Situations where one (or other) SLA Item applies to the same case more than once can emerge, unless we control them. This could happen, for instance, when changing a case’s priority, triggering the system to re-evaluate the “Applicable when” conditions. If conditions are met, the specified actions will be executed again. In order to prevent these kinds of situations, we need to flag some fields to avoid multiple processing.
• You can’t change the length of the field ‘Name’. You’ll wonder why I highlight this :). Well, we are going to need to clearly differentiate each SLA Item from the next, especially if this turns out to be our default SLA (see next section) – and SLA Items lists can grow to be extremely long. It might be useful to establish a name/code standard.
• An SLA Item’s KPI can’t be edited after the record is created. Therefore, pay close attention to the selected KPI. You’ll find two by default: “Resolve by KPI” and “First Response By KPI”. The former measures case resolution while the latter measures first responses to a case. In upcoming posts I’ll share how to create new personalized KPIs to track as well.
• Even though the list of available actions for each situation (Success Actions, Warning Actions and Failure Actions) is very similar to the one on Workflows, NOT ALL actions are available: you can only Send Email, Create Record, Update Record, Assign Record and Change Status.
  
• Actions will be triggered as asynchronous workflows, so they might not happen at the right time. If the Async Service is down, they will not be set off automatically.
• At the moment, there is no supported way to set SLAs by using SDK. Hopefully this situation can be improved very soon.