Escalations
An escalation clock monitors various HEAT events. If an event does not occur in a prescribed period, HEAT executes an escalation action. The exact timing and actions of an escalation depend on how you configure the escalation. By default, escalations are defined for incidents, service requests, and tasks and automatically run unless you are using the Service Level Management module.
Escalations typically provide notification in a dashboard or in a business object form (such as an Incident Details form). It is up to the SDAService Desk Analyst or SDMService Desk Manager to take appropriate action based on such notifications.
You can define and manage escalations through service level packages (SLPService Level Package.s) and service level agreements (SLAService Level Agreements). An escalation is executed by the escalation engine when a triggering event occurs or condition exists, and can be affected by hours of operation and service level agreements. See Creating an Escalation.
|
Service level agreements associated with a service override any system escalations when service level agreements are associated with a request item. In the absence of service level agreements, default escalations are run. See Creating an Escalation. |
|
Do not delete the ServiceReq - Delivery Default escalation, as you will not be able to create and save new request offerings. |
Default Escalations
Default HEAT escalation states are provided for these events:
Incident
- Closing
- Resolution
- Response
- Waiting
Service Request
- Closing
- Delivery
- Response
- Waiting
Task
- Task Assignment - Acceptance
- Task Assignment - Completion
- Task Work Order - Acceptance
- Task Work Order - Completion
Factors Affecting Escalations
Escalation configurations define the business object and the field that the escalation is based on. An escalation is based on the status of a specified field in a business object form. For example, the IncidentClosing escalation is based on the value of the status field in the incident business object form.
- How form events are mapped to escalation clock activity: Because escalations are time-based, each has an escalation clock that you can configure to run, stop, reset, and so on based on the status of the specified form field. For example, the IncidentClosing escalation is configured so that when the Incident Status field is set to resolved, the escalation clock starts running.
- The number and target duration of escalation levels, and what action is taken when the target duration is exceeded: After the escalation clock starts, it runs for a specified period of time at one or more stages, or escalation levels. Escalation levels are defined by thresholds that must be reached to trigger a call for additional resources to meet a service level target or customer expectation. When the duration at any level is exceeded, the escalation engine takes an action that you specify. For example, the IncidentClosing escalation is configured so that if the escalation clock runs for more than one day, the system executes the Auto Close quick action. You can configure up to three escalation levels for each escalation. Each level can have its own target duration and action when the target duration is exceeded.
- Exceptions to field status that the escalation is based on: You can specify that different escalation levels be based on form fields other than the field that the escalation was based on originally. For example, you could specify that level 2 of the IncidentClosing escalation be based on the value of the Priority field instead of the Status field (which the escalation was originally based on).