The Approvals page covers how decisions get made; this one covers how the rules get written — how the system knows whose door to knock on when a leave request, overtime claim or expense claim is submitted.
The policy list
Company ▸ Settings ▸ Approvals (under Policy in the settings list) shows one card per request type — leave, overtime, claims… — each with its enabled switch and step count. Every type always has a policy (defaults ship built in), so there is no “not configured yet” here — only “on defaults” and “changed”.
The switch renders only for holders of the write permission; a read-tier holder sees the state without the switch.
The step editor
Opening a type opens its step editor. A policy is a sequence of steps, each naming an approver — A position (its holders at the request’s branch; people come and go, positions stay), The requester’s manager, or A specific person; the built-in defaults name the requester’s manager — optionally guarded by a condition that routes some requests through an extra step: long leaves (“days ≥ N”), particular leave types (“type in …”). A request that doesn’t match skips the step.
The same approver can’t be required twice by one policy — the editor simply refuses to offer them again.
Save lives in the console header; a read-only holder gets the whole editor with fields locked and actions absent — reading what the policy says is exactly what that tier is for.
The three invisible rules that matter most
- The routing snapshot. The moment a request is submitted, the policy is photographed into it — later edits change future requests, never in-flight ones. Anything else would rewrite every request still travelling.
- What a timeout does. Each step has a Time limit (hours), swept hourly; an overdue item goes the way the step’s If late says: Reject it, or Escalate it — handed to the step’s Escalate to position, badged “Escalated”. Escalation happens once: an item that runs out of time again after escalating, runs out while waiting on the requester’s answer, or finds nobody in the Escalate to position at its branch is rejected instead. A policy sets not just who decides but how long is too long, and what happens then.
- Disabling is not deleting. Switch a type’s policy off and its requests auto-clear — recorded on the chain as bypassed, not vanished. Right for a small team that doesn’t need sign-offs yet: the record stays, the gate lowers.