Escalation rules

What are escalation rules?

Escalation rules decide when a piece of work stops waiting on one person and moves to someone else. You write the condition down in advance; when it becomes true the system reassigns the item and tells the new owner.

Two conditions do most of the work: time passing, and a threshold being crossed. A ticket with no first reply after four hours climbs to the team lead. A credit note above 2,500 euro never reaches the team lead at all, because the amount sends it straight to the finance manager. Most ladders run both.

A reminder says the work is late and leaves it exactly where it was. If the item still carries the same name after the rule fires, nothing escalated.

Functional and hierarchical escalation

Escalation splits in two, and the line is what the person receiving the work brings to it. Atlassian uses both names in its incident management material.

Functional escalation passes the item to whoever is best equipped to resolve it, going on skills rather than seniority. In Atlassian's example a first responder traces the problem to another product and hands it to a developer of the same rank on that team. The receiver adds expertise.

Hierarchical escalation passes it on experience or position instead, from a junior person to a senior one and further up while it stays unresolved. The receiver adds authority: permission to approve the discount, sign off an emergency change, take somebody off other work, or phone the customer.

So the question when you design a rung is not who comes next in the org chart, but what that person can do that the current one cannot. If the only answer is that they are more senior, you probably needed the expert.

What sets a rule off

• A deadline passing. Dynamics 365 Customer Service splits this into a warning action while the target is only nearing violation and a failure action once it is breached.

• An amount above a limit. An approval step can be set to run only when a condition holds, and Microsoft's example for purchase requisitions is an amount over 10,000 dollars. That decides which rung an item enters at, before any clock starts. A contract tier or a customer who already complained this month sets the entry rung the same way.

• The same thing failing again. One failed payment run is an incident. The third in a week belongs with someone who can change the cause instead of rerunning the job.

• A queue that has stopped moving. Not the age of one item, the age of the oldest item in the queue. That number rising is the earliest sign a team is under water.

• An agent that is unsure, or over its budget. When an agent finds nothing in your documents or scores its own answer low, that is a condition worth writing down. Spending is a second one: the Power Platform admin center takes a monthly message limit per Copilot Studio agent and reports each as within limit, nearing limit or over limit. Whoever receives either has to be someone who can switch the agent off.

Four things a rule has to settle

The clock. Decide whether it runs at night and over the weekend. Dynamics 365 calculates warning and failure times against a customer service schedule, and Microsoft is blunt about skipping it: if no business hours record is selected, work hours are considered to be all day, every day. An SLA can also pause while a record is on hold, so time waiting on the customer does not count against your team.

Who receives it, by role. A rule pointing at a person breaks the day that person changes job. Assign to a role or a position in a hierarchy, or to an on-call schedule the way PagerDuty does.

What the receiver has to do, and by when. PagerDuty gives every rule an escalation timeout, the time a responder has to act before the incident moves on, 30 minutes by default. Acknowledging stops the policy escalating, which is why it has to mean something. A ladder where people acknowledge to stop the phone buzzing has no rungs left.

The ceiling. Dynamics 365 Finance makes the top an actual field: an escalation path is a numbered list of assignments ending in a final action, and Microsoft's example ends with Reject. PagerDuty lets a policy repeat up to nine times, after which the incident stays with the last user and stops notifying. A ladder with no top does not escalate forever. It circles until somebody happens to look.

A credit note ladder, worked out

A wholesaler issues credit notes for damaged and short deliveries. The amount decides where a request enters, the clock decides how it climbs, and both run on the company calendar of Monday to Friday, 08:00 to 17:00.

1. Up to 500 euro: the customer service team lead, 4 working hours. Most credit notes stop here.

2. 500 to 5,000 euro: the finance manager, 8 working hours. A request in this range enters here and never troubles the team lead.

3. Above 5,000 euro: the managing director, 2 working days. Also where anything against a customer in dispute starts.

One rule sits across all three: whoever raised the credit note cannot approve it, so a request entered by the finance manager starts a rung higher than its amount suggests. That is segregation of duties, and it is why a ladder is never a pure function of the amount.

Now the calendar. A 180 euro credit note arrives at 16:30 on Friday. Tier one has 4 working hours and 30 minutes of the working week are left, so the remaining 3.5 hours run on Monday morning and the deadline lands at 11:30 Monday. On a wall clock, the same request breaches tier one at 20:30 on Friday, breaches tier two around half past four on Saturday morning, and sits on the managing director's list before anyone is back at a desk.

If the managing director has not answered after two working days, the ladder does not loop back. The final action rejects the credit note and returns it to whoever raised it with the reason attached. A rejection is something somebody can act on. A fourth reminder is not.

What to watch out for with escalation rules

The escalation nobody owns. The rule mails a group address, three people read it, each assumes one of the others has it. A rule that does not put a single name on the item is a notification.

Everything escalating. Set the thresholds too tight and half the queue turns red, and red stops meaning anything. If a manager gets twenty escalations a day, none of them is an escalation.

The rung that is on holiday. An escalation to someone who is away is a two week delay with a timestamp on it. Power Automate lets an approver reassign a request themselves, but the sender cannot: the requester can only cancel and edit the flow. Absence belongs in the rule, through a role or an on-call schedule.

The rule nobody has read since. Ladders get written once, during a project, by people who knew who did what that year. Two role changes later they point at a team that no longer exists. Read yours against the current org chart once a year.

Three numbers tell you whether yours work. The share of items that escalate, per rule: a rule that fires on nearly everything has its threshold set wrong, a rule that never fires is dead weight. The time an item spends on each rung, which shows where the ladder stalls. And the share of escalations that resolved without the receiver doing anything: work the original owner sorted out while it sat one rung up was never an escalation. It was a queue short of people, or a deadline shorter than the job takes.