Overriding the Default Behavior for SLA Warnings and Violations

Sub Banner

The CloudSET SLA management configuration tool provides an option to nominate an individual as the recipient of any notifications to be sent if and when a warning timer fires or an SLA is violated.

It is also possible to configure the subject and message body to be used for these notifications.

However, there is often a requirement to issue notifications to alternative individuals or groups based on one or more criteria, e.g. associated organization, assigned group, SLA plan, region, ticket type, etc.
There might also be a requirement to prevent some or all of these notifications being issued.

The CloudSET SLA Management extension framework therefore provides enablers to allow the default behavior to be overridden or extended as described in the following steps.

Prevent Generation of Default Notifications

Prevent Generation of Default Notifications

The default notifications for SLA warnings and violations can be configured for each event in the Events tab (please see this article for full details: Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (SLA Events Tab) ).

From here it is possible to prevent some or all of the notifications by simply setting the recipient to the empty value (3).

Once the configurations are saved (4) having made these changes the SLA triggers will be regenerated without the notification actions.

Create a Trigger to Handle SLA Warnings

Create a Trigger to Handle SLA Warnings

Whenever an SLA warning timer fires a 'post hook' tag is applied to the ticket.

This tag will always take the form eventname_warned_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a warning occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

 

Create another Trigger to Handle SLA Violations

Create another Trigger to Handle SLA Violations

As with warnings, whenever a main SLA timer fires a 'post hook' tag is applied to the ticket indicating that a violation has occured.

This tag will always take the form eventname_violated_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a violation occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

Identifying Event Names

Identifying Event Names

Although it is possible to configure the labels used for display purposes (see Creating and Maintaining SLA Plans - (SLA Plans Tab) for full details), there is always a generic reference name for each event.

These generic names are used in the 'post hook' tags referred to in the above steps and can be located in the Events tab (10).

*Note: these generic names are also used in the names of the ticket fields used to record and maintain information about each event for monitoring and reporting purposes (see Monitor and Measure SLA Performance for full details)

Overriding the Default Behavior for SLA Warnings and Violations

Sub Banner

Overriding the Default Behavior for SLA Warnings and Violations

The CloudSET SLA management configuration tool provides an option to nominate an individual as the recipient of any notifications to be sent if and when a warning timer fires or an SLA is violated.

It is also possible to configure the subject and message body to be used for these notifications.

However, there is often a requirement to issue notifications to alternative individuals or groups based on one or more criteria, e.g. associated organization, assigned group, SLA plan, region, ticket type, etc.
There might also be a requirement to prevent some or all of these notifications being issued.

The CloudSET SLA Management extension framework therefore provides enablers to allow the default behavior to be overridden or extended as described in the following steps.

Prevent Generation of Default Notifications

Prevent Generation of Default Notifications

The default notifications for SLA warnings and violations can be configured for each event in the Events tab (please see this article for full details: Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (SLA Events Tab) ).

From here it is possible to prevent some or all of the notifications by simply setting the recipient to the empty value (3).

Once the configurations are saved (4) having made these changes the SLA triggers will be regenerated without the notification actions.

Create a Trigger to Handle SLA Warnings

Create a Trigger to Handle SLA Warnings

Whenever an SLA warning timer fires a 'post hook' tag is applied to the ticket.

This tag will always take the form eventname_warned_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a warning occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

 

Create another Trigger to Handle SLA Violations

Create another Trigger to Handle SLA Violations

As with warnings, whenever a main SLA timer fires a 'post hook' tag is applied to the ticket indicating that a violation has occured.

This tag will always take the form eventname_violated_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a violation occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

Identifying Event Names

Identifying Event Names

Although it is possible to configure the labels used for display purposes (see Creating and Maintaining SLA Plans - (SLA Plans Tab) for full details), there is always a generic reference name for each event.

These generic names are used in the 'post hook' tags referred to in the above steps and can be located in the Events tab (10).

*Note: these generic names are also used in the names of the ticket fields used to record and maintain information about each event for monitoring and reporting purposes (see Monitor and Measure SLA Performance for full details)

Overriding the Default Behavior for SLA Warnings and Violations

Sub Banner

The CloudSET SLA management configuration tool provides an option to nominate an individual as the recipient of any notifications to be sent if and when a warning timer fires or an SLA is violated.

It is also possible to configure the subject and message body to be used for these notifications.

However, there is often a requirement to issue notifications to alternative individuals or groups based on one or more criteria, e.g. associated organization, assigned group, SLA plan, region, ticket type, etc.
There might also be a requirement to prevent some or all of these notifications being issued.

The CloudSET SLA Management extension framework therefore provides enablers to allow the default behavior to be overridden or extended as described in the following steps.

Prevent Generation of Default Notifications

Prevent Generation of Default Notifications

The default notifications for SLA warnings and violations can be configured for each event in the Events tab (please see this article for full details: Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (SLA Events Tab) ).

From here it is possible to prevent some or all of the notifications by simply setting the recipient to the empty value (3).

Once the configurations are saved (4) having made these changes the SLA triggers will be regenerated without the notification actions.

Create a Trigger to Handle SLA Warnings

Create a Trigger to Handle SLA Warnings

Whenever an SLA warning timer fires a 'post hook' tag is applied to the ticket.

This tag will always take the form eventname_warned_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a warning occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

 

Create another Trigger to Handle SLA Violations

Create another Trigger to Handle SLA Violations

As with warnings, whenever a main SLA timer fires a 'post hook' tag is applied to the ticket indicating that a violation has occured.

This tag will always take the form eventname_violated_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a violation occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

Identifying Event Names

Identifying Event Names

Although it is possible to configure the labels used for display purposes (see Creating and Maintaining SLA Plans - (SLA Plans Tab) for full details), there is always a generic reference name for each event.

These generic names are used in the 'post hook' tags referred to in the above steps and can be located in the Events tab (10).

*Note: these generic names are also used in the names of the ticket fields used to record and maintain information about each event for monitoring and reporting purposes (see Monitor and Measure SLA Performance for full details)

Overriding the Default Behavior for SLA Warnings and Violations

Sub Banner

Overriding the Default Behavior for SLA Warnings and Violations

The CloudSET SLA management configuration tool provides an option to nominate an individual as the recipient of any notifications to be sent if and when a warning timer fires or an SLA is violated.

It is also possible to configure the subject and message body to be used for these notifications.

However, there is often a requirement to issue notifications to alternative individuals or groups based on one or more criteria, e.g. associated organization, assigned group, SLA plan, region, ticket type, etc.
There might also be a requirement to prevent some or all of these notifications being issued.

The CloudSET SLA Management extension framework therefore provides enablers to allow the default behavior to be overridden or extended as described in the following steps.

Prevent Generation of Default Notifications

Prevent Generation of Default Notifications

The default notifications for SLA warnings and violations can be configured for each event in the Events tab (please see this article for full details: Refine the Behaviour of Events, e.g. Pausing, Notifications, Violation Counts - (SLA Events Tab) ).

From here it is possible to prevent some or all of the notifications by simply setting the recipient to the empty value (3).

Once the configurations are saved (4) having made these changes the SLA triggers will be regenerated without the notification actions.

Create a Trigger to Handle SLA Warnings

Create a Trigger to Handle SLA Warnings

Whenever an SLA warning timer fires a 'post hook' tag is applied to the ticket.

This tag will always take the form eventname_warned_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a warning occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

 

Create another Trigger to Handle SLA Violations

Create another Trigger to Handle SLA Violations

As with warnings, whenever a main SLA timer fires a 'post hook' tag is applied to the ticket indicating that a violation has occured.

This tag will always take the form eventname_violated_post where event name corresponds to the metric or event being measured and to which the warning applies (see Identifying Event Names below).

A trigger can be used to identify the presence of these tags (5) and take the appropriate action (7) when a violation occurs, e.g. notify a group, team lead or manager, reassign or reprioritize the ticket, etc.

Additional conditions can be introduced (6) an multiple triggers created to perform alternative actions if necessary.
However, remember to remove the 'post hook' tag to prevent the trigger firing on each subsequent ticket update.

Identifying Event Names

Identifying Event Names

Although it is possible to configure the labels used for display purposes (see Creating and Maintaining SLA Plans - (SLA Plans Tab) for full details), there is always a generic reference name for each event.

These generic names are used in the 'post hook' tags referred to in the above steps and can be located in the Events tab (10).

*Note: these generic names are also used in the names of the ticket fields used to record and maintain information about each event for monitoring and reporting purposes (see Monitor and Measure SLA Performance for full details)