---
title: "Approval policies"
description: "Who approves what, in what order — steps, conditions, what a timeout does, and why the routing snapshot matters."
---

> Documentation Index
> Fetch the complete documentation index at: https://peoplematter.app/llms.txt
> Use this file to discover all available pages before exploring further.

# Approval policies

The [Approvals](/en/docs/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.

> **Start from the defaults**
>
> Every type ships with a working default policy — let it run, and add steps the day a
> request genuinely needs a second pair of eyes. That beats designing a five-step flow
> before the first request exists.

Source: https://peoplematter.app/en/docs/approval-policies/index.mdx