Configure approval workflows
Decide who approves which requests: pick a preset or build a step-by-step chain, attach it to your leave policies, and set up substitutes so approvals never stall while an approver is away.
Before you start
- You need the HR or Admin role for the policies you configure.
- Three presets are ready out of the box: Manager approves, Manager, then HR, and HR only. They are starting templates — copies belong to your organization, and editing them never affects anyone else.
How a workflow is built
A workflow is an ordered list of steps. Each step names its approver in one of three ways:
- Direct manager — the requester’s manager from the reporting line (reporting lines may cross branches).
- Role — a holder of the HR or Admin role whose scope covers the requester; the most specific scope wins (team before branch before company).
- Specific person — one named person.
A requester is never their own approver: if a step resolves to the requester, the next candidate is chosen. If a step resolves to nobody at all (no manager at the top of the chain, no role holder covering the branch), the request is routed to an Admin and the gap is flagged in the audit trail — requests never disappear into a void.
Attaching workflows to policies
Each leave policy names its default workflow, and specific absence types can override it (for example: vacation follows Manager approves, while unpaid leave follows Manager, then HR). A policy without a workflow uses the built-in default: the requester’s direct manager approves.
The Leave policy section of Settings (under Organization) shows the attached workflow as the read-only Approval flow section:
Reported absence types (such as sick leave recorded on someone’s behalf) never go through approval — they are recorded as facts. See Record sick leave for an employee.
What approvers experience
- The request stays Pending until the last step decides. Each step’s decision — who, when, and any comment — is kept in the audit trail.
- A rejection at any step rejects the whole request; there are no partial states.
- Approvers always see the absence type of requests routed to them, even where visibility rules mask it elsewhere.
Substitutes and delegation
Each approver can have one substitute, in one of two modes:
- Standing — every request that would reach the approver goes to the substitute, for as long as the delegation exists.
- When absent — the substitute receives only requests whose dates overlap the approver’s own approved absence. Working remotely does not count as absent.
If an absent approver has no usable substitute, the request escalates up the approver’s own management chain to the first available person; as a last resort it goes to an Admin. Every substitution is recorded with its reason (standing, absence, or escalation), and the requester sees a note like “Jan Kowalski is away — the request will go to Eva Malá” before submitting (people are always shown with their full name).
Delegations do not chain: a substitute’s own delegation is never followed.
Automatic approvals
Three optional rules approve without a human decision; all of them are audited as decided by the system:
- Per absence type — requests of a type marked auto-approve (commonly remote work) are approved immediately on submission.
- Small requests — a step can approve requests up to a set number of working days automatically.
- Timeout — a step left undecided for a set number of working days is approved automatically.
A request that exceeds a blocked limit is never auto-approved — the block always wins. See Set absence limits and enforcement.