Service Manager

This is the latest version of the help for Ivanti Service Manager 2018. If you cannot find some of the features described in the help, you may be using an older version of the application. To upgrade the application, click here.
To view the help for the latest version of Service Manager, click here

Working with Escalations

•About Escalations

•Default Escalations

•Factors Affecting Escalations

•Creating an Escalation

•Adding Escalation Levels

•Modifying an Escalation Schedule

•Deleting an Escalation Schedule

•Working with Escalation Exceptions

•Watching Escalations

•About Resolution Details

•Example: Setting an Escalation Schedule by Priority

•Default Escalation Settings

About Escalations

An escalation clock monitors various Service Manager events. If an event does not occur in a prescribed period, Service Manager 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 Service Desk Analyst or Service Desk Manager to take appropriate action based on such notifications.

You can define and manage escalations through service level packages and service 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 Service Manager escalation states are provided for these events:

•Incident

•Service Request

•Task

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).