Configure SLA Breach Notification System

This article contains the following topics:

The system works in the following manner:

1. The administrator configures a communication template for SLA breach.
2. When an SLA is at risk, the system sends a notification to the phone number of the analyst who is associated with the ticket.
3. The analyst hears the notification and selects a response.
4. The system uses the response to execute a workflow action on the related ticket.

For more information about Service Level Management, see Manage Service Level Agreements.

Considerations

• To enable the application to generate SLA-related notifications, ensure that the following configuration parameters are set properly:
  • SLA_ENABLE_SUPPRESSION_ON_PENDING_ACTIONS - Set this parameter to Yes only when switching On SLA monitoring for the first time. After the initial enabling of SLA monitoring, set the parameter to No. When the parameter is set to No, the SLA actions are not suppressed. This setting enables the system to generate SLA actions of Assignment and Notification.
  • SLA_PROCESS_HIGHEST_ACTIONABLE_THRESHOLD_RULES - Always set this parameter to Yes. This parameter is useful when more than one threshold are breached at the time of applying a target to a ticket. For example, consider a situation where two thresholds with sort orders 1 and 2 are breached at the time of applying a target on a ticket. If this parameter is set to Yes, then only the actions for the Threshold with sort order 2 executes. The system ignores the Threshold with sort order 1.
    For more details about these parameters, see Service-Level Management Parameters.
• To enable a support group to receive the notifications, enable the SLA Escalation flag for that group. When a ticket is assigned to a group for which the SLA Escalation flag is disabled, SLA notifications are not processed for that group. However, the SLA targets do get applicable for that ticket.
  Example:
  Customer has an SLA Target where matching condition is: Ticket priority = Critical. The SLA Target is configured to send an email to the Assigned Group if there is no response to the ticket within 10 minutes.
  An analyst creates a ticket with Priority = Critical and assigns the ticket to the Service Desk (L1) group. The SLA Escalation flag is not enabled for Service Desk (L1) group.
  So, even though the SLA target is applied to the ticket, the system does send any SLA notifications to the group.

Set up a Communication Template for SLA Breach Notification

See Create and Manage Communication Templates for related information.

Enable External Notifications

To enable phone-based SLA Breach Notifications, configure the External Notifications system for your slice.

Follow these steps:

1. Navigate to MANAGE, ADMINISTRATION, Tools, Slice Configuration, External Notifications.
2. Select the check box Enable External Notification Configuration?.
3. Select MIR3 from the System Name drop-box.
4. Enter the URL and credentials for your MIR3 server.
5. Configure the Response Actions.
6. Configure the following Job Triggers:
   1. Relay Phone Messages
   2. Track and Monitor Message Responses
      See Create and Manage Job Triggers for more information.
7. Click Apply Changes.

Configure Response Actions

You can enable your analysts to execute workflow actions on the related tickets through the notification system. For this purpose, configure a set of response options for analysts within the notification system. When analysts view a notification, they can select an option to execute the corresponding workflow action on the related ticket.

Follow these steps:

1. Navigate back to External Notifications. In the Notification Failed Default Action field, set the applicable action on the related ticket if the notification mechanism fails.
2. In each Response Options field, enter the options that are available to analysts.
3. In each Associated Workflow Action field, select the corresponding action that is executed when the analyst selects that response option. Consider the following rules while mapping the workflow actions:
   • Only the workflow actions that do not have a special function are available for the mapping.
   • The system considers only Set Fields in the workflow action, while processing the response. Matching Conditions, Required Fields, and Permissions that are associated with the Workflow action are not considered.

You can configure up to five response options.

You can use this system, without configuring the response actions, for only sending out notifications.