It might be the case that your SLA Plans, Working Hours and Non-Working Days specifications are determined by the type of ticket group assignment or by a combination of conditions other than just priority.
- It might be a requirement to respond and resolve tickets of type problem sooner than those classified as questions
- It might be that tickets classified as questions aren't subject to SLA measurement
- You might have a specific set of custom ticket types and/or classifications to determine which set of SLA specifications should be assigned
- It might be that the group assignment determines the level of importance and so how soon a response and resolution should be assigned
It will therefore be necessary to introduce additional "Hybrid" triggers to apply the SLA PLan and Region to your tickets.
Introduce Triggers to Apply SLA Assignments
If introducing manually created "Hybrid" triggers to determine SLA Assignment, then they should be positioned in the trigger order immediately before the SLA generated triggers named "SLA3 Assign Default Region" and "SLA3 Assign Default SLA".
These two triggers will then assign a default SLA Plan and Region to a ticket if required and they haven't been assigned by your "Hybrid" SLA Assignment triggers (see Assigning a Default SLA Plan and Region).
Defining the Rules and Actions for the "Hybrid" SLA Assignment Triggers
The "Hybrid" triggers should be based on the SLA generated triggers named "SLA3 Assign Default Region" and "SLA3 Assign Default SLA", to ensure that the appropriate action is taken to assign or reassign the SLA Plan or Region (1).
*Important Note Concerning SLA Custom Drop Down Fields and Triggers
Due to a current limitation in the Zendesk API it is necessary to recreate the SLA3 SLA and SLA3 Region custom field drop downs each time the configurations are updated and saved.
When this occurs all references to the custom field and its option values in any trigger conditions or actions are lost.
It is therefore important that trigger conditions and actions always reference the tag values and not the custom filed option values.
However, it is possible to make reference to the SLA3 SLA and SLA3 Region custom field drop downs and option values within Views and Insights reports and metrics, since these references will not be lost if and when the field is recreated.
Please see Assigning a Default SLA Plan and Region for full instructions showing how to identify the appropriate tag values to enter in the Ticket: Add tags action.
The trigger conditions should include all rules used to determine which SLA Plan or Region to assign depending upon the ticket type, group assignment and/or any other classifications.
*Identifying a Change of SLA Plan or Region
If those trigger fires a tag is applied to the ticket (3) to force a request to the SLA Management server to recalculate the due dates/times for all events based on the assigned SLA Plan and Region.
The tag is subsequently removed by the SLA Management Server, but in order to prevent unnecessary requests each time the ticket is updated the trigger conditions should check to ensure the SLA hasn't already been appropriately set (4).
Force SLA Reset and Recalculation on Change of Type or Classification
Since the SLA Assignment might change during the life of the ticket due to a change of type, group assignment or alternative classification it is important to reset the SLA (1) if any of the defining conditions change (2).
This should be actioned using a trigger positioned immediately before the "Hybrid" triggers used to assign the SLA Plan and SLA Region (4).
Doing so will force one of the SLA assignment triggers to fire, resetting the appropriate SLA Plan and/or Region and forcing a recalculation of the due date/times for all events.
Setting "No SLA" when SLA Assignment isn't Required
If there are circumstances and conditions under which SLA performance shouldn't be measured for a ticket it is important to consider the possibility that the conditions might have changed and an SLA Assignment might already have been made for the ticket.
A trigger will be required (1) to identify the conditions under which the ticket shouldn't be subject to SLA (2).
If the conditions have changed the SLA should already have been removed for the ticket by the trigger described in the previous step and now this trigger must apply an SLA Plan option to prevent the default SLA being applied (3).
This trigger must also include the tag (4) that will force the recalculation of the due date/time for all events using a set of SLA Plan specifications as follows:
If there is a possibility that the SLA assignment could be removed from a ticket it will be necessary to create an SLA Plan to force the recalculation, clear out the event due dates/times and stop the timers.
This SLA Plan should be named "No SLA" (1) or something appropriate that clearly indicates the reason why there are no SLA event due dates/times displayed in the SLA Assistant.
The timing specifications for all events should be set to zero hours and minutes (2) and since this will be te case regardless of ticket priority the Singular dimension can be selected (3).
If this SLA is assigned to a ticket the due date/time calculation for all events will always return an empty value, replacing any existing values and stopping the timers if previously started by an alternative SLA assignment.
*Note: this "No SLA" plan can be used as the default SLA to clearly indicate in the SLA Assistant when a ticket has not been placed under SLA performance measurement.