Initializing the SLA Lifecycle

Sub Banner

If multiple SLA Plans have been created and there is a mixture of Singular and Priority based settings, or if a Custom Priority has been utilized, there might be a need to adjust some trigger conditions to ensure the SLA Lifecycle is initiated for all tickets.

This is achieved as follows:

Update and/or Replicate the Default LCState Trigger

Update and/or Replicate the Default LCState Trigger

Since SLA3 is driven and controlled by a process defined by the chosen Model, it is necessary to start the process for a ticket by setting the initial lifecycle state.

  • If a ticket is created using the Zendesk browser then the lifecycle state is set by the CloudSET SLA Management App.
  • However, if a ticket is created remotely via email or an alternative to an App enabled Zendesk browser it is necessary to initiate the lifecycle state using a trigger (2).
  • If the trigger finds an empty value in the Lifecycle State (3), the ticket will be tagged to initiate the lifecycle and force the calculation of the SLA event timers (4).
  • However, if one or more SLA Plans is dependent upon the setting of a Priority, the trigger is generated with a condition to prevent firing unless a system Priority has been selected (5).

Update and or Replicate the Generated Trigger

  • If there are any SLA Plans that aren't dependent on the setting of a Priority (Singular dimension) or if a custom Priority is in use it will be necessary to change this trigger condition and/or create replicant triggers with conditions that will ensure the lifecycle state is always initiated for each type of SLA Plan.
  • Any updates made to the generated version of this trigger won't be overwritten if and when any configuration changes are saved.

Initializing the SLA Lifecycle

Sub Banner

Initializing the SLA Lifecycle

If multiple SLA Plans have been created and there is a mixture of Singular and Priority based settings, or if a Custom Priority has been utilized, there might be a need to adjust some trigger conditions to ensure the SLA Lifecycle is initiated for all tickets.

This is achieved as follows:

Update and/or Replicate the Default LCState Trigger

Update and/or Replicate the Default LCState Trigger

Since SLA3 is driven and controlled by a process defined by the chosen Model, it is necessary to start the process for a ticket by setting the initial lifecycle state.

  • If a ticket is created using the Zendesk browser then the lifecycle state is set by the CloudSET SLA Management App.
  • However, if a ticket is created remotely via email or an alternative to an App enabled Zendesk browser it is necessary to initiate the lifecycle state using a trigger (2).
  • If the trigger finds an empty value in the Lifecycle State (3), the ticket will be tagged to initiate the lifecycle and force the calculation of the SLA event timers (4).
  • However, if one or more SLA Plans is dependent upon the setting of a Priority, the trigger is generated with a condition to prevent firing unless a system Priority has been selected (5).

Update and or Replicate the Generated Trigger

  • If there are any SLA Plans that aren't dependent on the setting of a Priority (Singular dimension) or if a custom Priority is in use it will be necessary to change this trigger condition and/or create replicant triggers with conditions that will ensure the lifecycle state is always initiated for each type of SLA Plan.
  • Any updates made to the generated version of this trigger won't be overwritten if and when any configuration changes are saved.

Initializing the SLA Lifecycle

Sub Banner

If multiple SLA Plans have been created and there is a mixture of Singular and Priority based settings, or if a Custom Priority has been utilized, there might be a need to adjust some trigger conditions to ensure the SLA Lifecycle is initiated for all tickets.

This is achieved as follows:

Update and/or Replicate the Default LCState Trigger

Update and/or Replicate the Default LCState Trigger

Since SLA3 is driven and controlled by a process defined by the chosen Model, it is necessary to start the process for a ticket by setting the initial lifecycle state.

  • If a ticket is created using the Zendesk browser then the lifecycle state is set by the CloudSET SLA Management App.
  • However, if a ticket is created remotely via email or an alternative to an App enabled Zendesk browser it is necessary to initiate the lifecycle state using a trigger (2).
  • If the trigger finds an empty value in the Lifecycle State (3), the ticket will be tagged to initiate the lifecycle and force the calculation of the SLA event timers (4).
  • However, if one or more SLA Plans is dependent upon the setting of a Priority, the trigger is generated with a condition to prevent firing unless a system Priority has been selected (5).

Update and or Replicate the Generated Trigger

  • If there are any SLA Plans that aren't dependent on the setting of a Priority (Singular dimension) or if a custom Priority is in use it will be necessary to change this trigger condition and/or create replicant triggers with conditions that will ensure the lifecycle state is always initiated for each type of SLA Plan.
  • Any updates made to the generated version of this trigger won't be overwritten if and when any configuration changes are saved.

Initializing the SLA Lifecycle

Sub Banner

Initializing the SLA Lifecycle

If multiple SLA Plans have been created and there is a mixture of Singular and Priority based settings, or if a Custom Priority has been utilized, there might be a need to adjust some trigger conditions to ensure the SLA Lifecycle is initiated for all tickets.

This is achieved as follows:

Update and/or Replicate the Default LCState Trigger

Update and/or Replicate the Default LCState Trigger

Since SLA3 is driven and controlled by a process defined by the chosen Model, it is necessary to start the process for a ticket by setting the initial lifecycle state.

  • If a ticket is created using the Zendesk browser then the lifecycle state is set by the CloudSET SLA Management App.
  • However, if a ticket is created remotely via email or an alternative to an App enabled Zendesk browser it is necessary to initiate the lifecycle state using a trigger (2).
  • If the trigger finds an empty value in the Lifecycle State (3), the ticket will be tagged to initiate the lifecycle and force the calculation of the SLA event timers (4).
  • However, if one or more SLA Plans is dependent upon the setting of a Priority, the trigger is generated with a condition to prevent firing unless a system Priority has been selected (5).

Update and or Replicate the Generated Trigger

  • If there are any SLA Plans that aren't dependent on the setting of a Priority (Singular dimension) or if a custom Priority is in use it will be necessary to change this trigger condition and/or create replicant triggers with conditions that will ensure the lifecycle state is always initiated for each type of SLA Plan.
  • Any updates made to the generated version of this trigger won't be overwritten if and when any configuration changes are saved.