Summary

An escalation policy offers a comprehensive view of who receives notifications and through which channels along the escalation path. A single escalation policy can be associated with multiple shifts. But you can also create a unique escalation policy tailored for a specific shift. In addition, an escalation policy enables users to define conditions based on multiple ticket standard and custom fields to tailor escalations as per unique circumstances.

Step 1

Select the second tab – Escalation Policies – on the on-call schedule page and click on Create escalation policy. 

Step 2

Give the escalation policy a name. Choose the shifts to apply this escalation policy to. 

Step 3

Define the condition that should trigger this escalation policy. In this example, escalation will be triggered if the incident priority is Urgent. You can choose additional conditions to fine tune the reason for escalation.

Step 4

Design the escalation path by:

• Specifying the agents who must be notified
• How soon after the incident is assigned to the agent group should they be notified
• What channels should they be notified on
• How soon should they be renotified in case the incident remains unacknowledged or unresolved 

In the example given below, if the incident priority is Urgent, primary on-call agents are to be notified immediately (at 0 minutes) via phone call, email, & SMS. If the incident remains unacknowledged or unresolved for the next 5 minutes, the primary on-call agents will be renotified over phone call, email, SMS, and WhatsApp.

If on-call agents specified in the first level of escalation fail to acknowledge the incident, the notifications are escalated to level 2. In the above example, level 2 escalation requires primary and well as secondary on-call agents to be notified. Similarly, an incident can be escalated to up to five levels if it remains unacknowledged or unresolved.

By default, the Escalation Path features a single level mapped to the primary on-call roster. However, you can customize this setup as per your unique requirements. Some examples include:

• Adding primary, secondary, and tertiary agents to level 1 while adding subject matter experts to level 2

• Adding one or more subject matter experts (who are not agents) to the same level as the primary on call

• Adding primary and secondary agents to level 1, tertiary on-call agents to level 2, and subject matter experts to level 3

• Retaining just 2 levels or adding up to five levels of escalation

Each level can accommodate up to 10 agents and/or subject matter experts, and there are 5 levels available. 

Step 5

Once you’ve designed the escalation path, specify the number of times the path could be repeated in case an incident remains unacknowledged. 

Step 6

If you want, you can also notify up to 10 stakeholders – both agents & requesters – about the progress of an incident through a notification channel of your choice. While stakeholders can’t take action on an incident, this feature enables them to stay updated.

Step 7

Remember to Save the escalation policy before you exit the page.

Dynamic re-evaluation of escalation paths

Escalation policies (EPs) are dynamically re-evaluated whenever changes are made to any ticket field that's available as a match condition for escalation paths, including custom fields  while the ticket remains unassigned. Once an agent is assigned to the ticket, EPs are no longer evaluated, regardless of any subsequent field changes, until the ticket becomes unassigned again.

While unassigned, this re-evaluation ensures on-call notifications are always triggered according to the escalation policy most relevant to the ticket's current state, not the state it was in when the policy first matched.

Example: An on-call schedule has two escalation policies — EP1, matched on Impact = Low, configured to send e-mails; and EP2, matched on Impact = High, configured to call on-call agents.

A ticket comes in with Impact = Low. EP1 matches, and e-mails start going out. If Impact is updated to High (via workflow, manually, or otherwise) before the ticket is assigned to an agent, EP2 now matches instead, and phone calls are triggered.

If, instead, an agent gets assigned to the ticket while it's still on EP1 (Impact = Low), escalation stops at that point. Even if Impact is later changed to High, EP2 will not be evaluated and calls will not be triggered — the ticket is already considered acknowledged. Re-evaluation only resumes if the ticket is unassigned again.

This behavior reduces missed notifications caused by a stale escalation path match while a ticket is still unassigned, while ensuring that once an agent has picked up the ticket, they aren't interrupted by further escalation noise.

Note: 

1. In case no escalation path is triggered when an incident is assigned to a group with an on-call schedule, the system will default to round-robin.

2. The order of esclation policies matters! For an incident, if there is an active shift with 2 matching escalation polciies, then the policy on top will be executed.

3. Download VCF files to identify calls from Freshservice.

Next > Create an override for on-call