- Home
- Forms, workflows and approvals
- Setting up escalation policies
Setting up escalation policies
An escalation policy is a named plan for inaction. It says what happens when a step sits waiting: who is reminded, after how long, and at what point the work is taken off the person and given to somebody else.
Policies are built once and reused, so “three working days, then a nudge, then the manager” is written down in one place rather than rebuilt inside every workflow.
An escalation policy is not the same as the escalation contact in People settings. That contact is who people report to when every position above them is vacant, and has nothing to do with chasing a waiting step. See How positions work.
Where it is
Section titled “Where it is”Choose Admin, then Process in the left-hand menu and Escalation policies.
What the list tells you
Section titled “What the list tells you”Each policy shows what it is used for, how its days are counted, and how many stages it has.
Two things to decide before the stages
Section titled “Two things to decide before the stages”What it is used for. A policy is written either for approval requests or for other processes. The distinction keeps approval chasing separate from ordinary workflow steps, because the two want different tone and different timing.
How days are counted — working days (Monday to Friday) or calendar days.
This is the setting people get wrong, and it is worth thinking about properly. Three calendar days from a Thursday is Sunday, and a reminder that lands on Sunday is read on Monday with everything else. Three working days from a Thursday is Tuesday. For anything a person has to act on, working days is usually what you meant.
Calendar days are right where the deadline is real rather than administrative — something expiring, or a legal window that does not pause for the weekend.
The stages
Section titled “The stages”A policy is an ordered ladder. Each stage carries how long to wait and what to do when that time passes.
Actions are of two kinds: remind somebody, or reassign the work to somebody else.
The offsets are measured from the point the step started waiting, not from the previous stage — so a ladder of two, five and ten days fires on those days, rather than two, then seven, then seventeen.
Writing a ladder that works
Section titled “Writing a ladder that works”Start with a reminder, not a reassignment. The first stage should assume the person meant to act and forgot, because that is usually true.
Reassign only where somebody else can genuinely do it. Moving an approval to a manager works. Moving somebody’s own review form to their manager does not — nobody else can write it.
Three stages is usually enough. A ladder with six is a ladder nobody reads to the end of, and the later rungs fire long after the moment anybody cared.
Where a policy is used
Section titled “Where a policy is used”Policies do nothing on their own. A workflow step points at one, and the step inherits its ladder — see How workflow launch works for what a step is and when it becomes active.
Because a policy is shared, editing one changes every step pointing at it. Check what uses a policy before you shorten its timings.
What happens when you save
Section titled “What happens when you save”A policy applies to steps that are waiting from then on. It does not reach back into ladders already part-way through, so a step that has already passed its first stage keeps the timings it started with.

