Approval workflows

Leave → Settings → Workflow holds the routing that decides who approves what.

Most organizations don’t need to touch it. The page says so:

The leave approval workflow. Every leave request runs through it — use branches inside to route by leave type, duration, and so on. Most companies just need the per-employee approver on the Workforce page; this is for custom routing.

Leave runs on one workflow. There’s no list of competing workflows to maintain — all the variation lives inside the graph as branches.

If none exists yet, the page offers Create leave workflow. Otherwise a single row opens the editor.

Two views of the same thing

The editor has Basic and Advanced tabs. Both edit the same underlying graph:

Basic is a table of steps that run in order. Use it when approval is a straight chain, optionally with steps that get skipped under certain conditions.
Advanced is a canvas with branching. Use it when different requests need to take genuinely different paths, or when a path should end in an automatic rejection.

Basic is disabled when the graph branches — the hint reads This flow branches, so it needs the advanced editor. Unsaved edits and hand-arranged node positions carry across when you switch views.

Approver types

Both editors offer the same four choices:

Choice	Resolves to
Leave approver	The employee’s designated leave approver, falling back to their reporting manager
Reporting manager	The employee’s manager
A role	Everyone holding the chosen role in the organization
Claim approver	The employee’s designated claim approver

Leave approver is the default and covers most cases — it means “whoever is set on this person’s record”.

Basic: an ordered chain

The table has one row per step: #, Approver, Role, Who has to approve.

Select Add step.
Pick the Approver. If you choose A role, a Role dropdown appears and is required.
On role steps, choose Who has to approve:
- Any one of them — First person to approve moves it forward.
- A specific number — reveals a count field, minimum 2.
- All of them, in order — Each person approves in sequence; all must approve.
Non-role steps are always Single approver.
Repeat for further steps. Use the row menu for Move up / Move down.
Select Create, or Save new version on an existing workflow.

Conditional steps

The row menu also offers Only run when…, which opens a condition panel:

Only run this step when all of the following are true — otherwise the request skips straight to the next step.

Conditions are built from two facts about the request:

Duration (days) — is less than, is at most, is at least, is greater than, equals, is not
Leave type — is, is not, is one of, is none of

So “director sign-off only for leave of 10 days or more” is a step gated on Duration (days) is at least 10.

Saving is blocked with a clear toast if a step is incomplete — Add at least one approval step, Every step set to “A role” needs a role selected, or Every “only run when” condition needs a value — otherwise the step would never run.

Advanced: the branching canvas

The canvas has four node types:

Node	Purpose
Start	Where every request enters — labelled Leave request submitted
Approval	A person or pool who must approve
Branch	Splits the path based on conditions
Approved / Rejected	Terminal outcomes

Add nodes from the Add palette. The two outcome nodes are singletons — adding one again just selects the existing node.

A Branch node holds an ordered list of cases plus an Otherwise path. Cases are checked top-down and the first whose conditions all match wins. Case labels are generated from the conditions themselves, so a case reads Duration (days) ≥ 5 and Leave type is Annual.

Validation and testing

A panel at the top of the canvas shows live issue counts, and offending nodes get a red ring. The checks include: exactly one start node, at least one approval step, at least one outcome node, every node connected and reachable, every branch case connected and given conditions, every branch’s Otherwise path connected, roles selected, and no loops — approval graphs must be acyclic.

Test opens a sample tester: Enter request facts to highlight the exact path the engine would take. Type a duration and pick a leave type, select Trace, and the canvas highlights the path with a Result of Approved, Rejected, no outcome reached or flow dead-ends (not connected).

Use it before saving anything non-trivial.

Versioning

Saving an existing workflow creates a new version rather than editing in place. Requests already in flight keep the version they started on — the basic editor spells this out: Saving creates v3; in-flight requests keep their snapshot.

What happens at runtime

Beyond the graph you drew, three behaviours are worth knowing.

The requester is never their own approver. Any approver pointer that resolves to the requester is dropped, and a delegation chain that loops back to them is filtered out.

Out-of-office re-routing. If a resolved approver is themselves on approved leave that day, your organization’s out-of-office policy for leave decides what happens: leave it unchanged, replace them with their manager (a single hop, no chaining), or drop them and add everyone with blanket leave-approval rights. This is why “who’s out” is computed from the leave module itself.

Nobody-to-route-to is caught early. If a step resolves to no one, everyone with blanket approval rights is surfaced so the request can’t silently stall. And if the chain can’t resolve at submit time, the employee gets told immediately:

Cannot submit — you have no assigned manager. Please contact HR.
Cannot submit — no approver is assigned and you have no manager to fall back to. Please contact HR.
Cannot submit — your leave approver and reporting manager are set to yourself. Please contact HR.

Cancellations use the same workflow

When an employee cancels approved leave on a type where cancellation needs approval, the cancellation request runs on the same workflow the original ran on. You don’t configure a separate cancellation flow.