This article describes the procedure involved to install and use the components required to enable the complete removal of SLA assignment and all associated SLA data from a ticket.
*Note: This article covers the procedure and components involved to remove SLA if only Response and Solve events are in use. Please raise a ticket via firstname.lastname@example.org should you have a need to implement complete SLA removal if your setup involves additional event timers.
Deploy the Configuration to Install the Required Macro and Triggers
Locate the configuration containing the macro and triggers required to completely remove an SLA assignment from a ticket (4) - within the Shared Configurations with migration.zendesk.com (3).
Select the deploy link (5) to start the deployment process.
*Note: Please raise a ticket via email@example.com should the configuration not be available to your Zendesk account
Review the Triggers to be Deployed
A dialogue will be presented within which it is possible to review the list of components to be deployed, including the list of triggers (6).
Review the Macros to be Deployed
Confirm the correct macro is also included within the configuration (7) and select the Deploy link (8) to install the macro and triggers in your Zendesk account.
Review the log to Confirm Successful Deployment
Once all components in the configuration have been processed the Deployment details log will be presented and the log should report successful deployment for all components (9).
*Note: If the log reports a failure to deploy any of the components then please raise a ticket via firstname.lastname@example.org.
Reposition the Triggers in the Trigger Order
Once the new triggers have been deployed it will be necessary to manually reposition them in the trigger order to ensure they fire before the trigger named "SLA3 Assign Default LCState" (11).
**Important Next Step ** to Prevent Immediate SLA Re-Assignment
Before attempting to run the macro and triggers it is important to update the conditions in the trigger named "SLA3 Assign Default LCState" (13) to prevent firing if the ticket has been tagged with "sla_removed" (14).
This tag is applied to the ticket if and when SLA has been removed from the ticket, so without this condition the trigger would fire to immediately reassign SLA if rules are in place that reapply the default or specific SLA and Region values.
Run the Macro to start the SLA Removal Process
Use the new macro against a ticket with an unwanted SLA Assignment (15) to apply the fixed private comment (16) creating a record in the thread of the SLA removal, who performed the removal and the date/time stamp.
The Private Comment causes the First Trigger to fire
The presence of the private comment will cause the trigger named "SLA3 Remove SLA from Ticket (start) - No Updates" to fire (17).
This trigger will remove some of the SLA data, tag the ticket with "sla_removed" (18) and make a request to the CloudSET SLA Management service to complete the removal process.
The CloudSET SLA Management Services cleans out SLA Ticket Field Values
The CloudSET SLA Management service will update the ticket (19) to remove values held in fields specifically used to hold SLA data (20).
Refresh the Apps to Hide the SLA Assistant
If the ticket form is still open when the removal process completes all SLA events and associated data will have been removed, but the SLA Assistant might still be visible in the Apps panel (22).
If this is the case then the SLA Assistant can be permanently hidden by refreshing the Apps (23).
Automating Complete SLA Removal
This article provides a step by step procedure explaining how to manually remove SLA from a ticket with an unwanted SLA assignment, using a macro and trigger combination.
Upon completion of the procedure the trigger named "SLA3 Remove SLA from Ticket (start) - No Updates" (1) will fire if and when the macro is used to apply the fixed private comment (2).
Should there be a requirement to automate the complete removal of SLA then this can be achieved by updating the conditions for this trigger to fire according to your rules (2 and 3).
If the rules are complex then a separate version of this trigger can be cloned to allow the use of complex conditions without the need to check for the private comment.
*Note: obviously please be careful to ensure the rules are implemented correctly to avoid accidentally removing SLA from your tickets
Re-Applying SLA after Removal
The SLA Lifecycle Process is Restarted
Once the "sla_removed" tag is removed and provided an SLA Plan and Region are selected the trigger named "SLA3 Assign Default LCState" will fire (5) thus requesting the CloudSET SLA Management service to restart the SLA lifecycle (6).
The Recalculated SLA Events will be Presented in the SLA Assistant
The CloudSET SLA Management service will recalculate the due date/time for each SLA event, the timers will be restarted and the associated information will be presented in the SLA Assistant (8).
*Note: If still focused on the ticket form when the reapplication process completes it might be necessary to refresh the Apps (7) to permanently display the SLA Assistant.