The thing that actually delays payroll is an unapproved request
Not a missing feature — an approver on leave. Klok's chains handle the ordinary case and the awkward one: cover for whoever is away, escalation when a request sits too long, and separate routes for exceptions that need a different signature.
Chains You Configure
Who approves what, in what order, per company and per request type. Not a fixed two-step hierarchy everyone has to bend around.
Coverage For Absentees
When an approver is away, cover is defined in advance so requests keep moving instead of piling up behind one person.
Escalation On Silence
Requests that sit unactioned escalate rather than waiting indefinitely for someone to remember.
Variants For Exceptions
Some decisions need a different route — hiring over a sanctioned budget, for instance, escalates through its own chain rather than the everyday one.
The delay is a person, not a process
Ask why payroll ran late and the answer is almost never the calculation. It is that eleven attendance corrections sat unapproved because the plant manager was on leave and nobody had the authority to act in his place.
A workflow engine that only models the happy path does not help with this. It routes the request correctly to somebody who is not there.
Cover, escalation and exceptions
Klok's chains handle the three cases that actually occur. Cover names who acts when an approver is away, so absence redirects the queue instead of stopping it. Escalation moves a request up after a configured silence, because a request nobody has refused is not the same as a request nobody has seen. Variants allow a different chain for the awkward case — an over-budget hire, an expense above a threshold, a leave request that breaches policy — so the exception is escalated by design rather than by somebody noticing.
Configured once, applied everywhere
The same chains serve leave, expenses, attendance corrections, headcount and profile changes. That matters more than it sounds: a company that configures approvals separately per module ends up with four subtly different definitions of who may approve what, and discovers the differences during an audit.
What happens to a request that nobody answers
Raised
An employee submits. The chain for their grade and entity determines who sees it, in what order.
Covered
If the approver is on leave, their cover receives it — the queue redirects rather than stalls.
Escalated
Silence past the configured window moves it up. Nobody has to notice that nobody responded.
Settled
Approved or refused, with the reason recorded and the outcome flowing into the register or the run.
Approvals & Workflows FAQs
What happens if an approver is on leave?
The chain carries cover and escalation, so the request moves instead of waiting for somebody's return — a covering approver can act, and an unanswered request escalates rather than rots. Stalled approvals are the reason people route around systems; once "it is stuck with X who is travelling" stops being true, the informal WhatsApp approval culture that undermines every policy quietly dies.
Can someone approve their own request?
No — self-approval is guarded, including the subtler versions where a person sits in their own chain through a role. It is an obvious hole that a surprising number of systems leave open, and it is exactly the first thing an auditor checks in an expense process. The guard is enforced by the software, not by hoping the org chart never makes it possible.
Can approval rules differ by type and amount?
Yes — chains are configured per process, and variants route by what is being approved: a routine leave request does not need the sign-off depth of an over-budget hire or a large claim. Escalation policies bind to the variant, so the exceptional path is defined in advance rather than improvised when the exception arrives, which is precisely when nobody improvises well.
Is every approval recorded somewhere defensible?
Every action in a chain — approve, reject, escalate, cover — lands in the append-only audit trail with who and when. When an employee asks why a claim was refused, or an auditor asks who authorised a payment, the answer is a recorded decision by a named person, not a reconstruction from email. Approvals are exactly the records disputes are made of.
Do approvals work from the phone?
Yes, with the same chains and guards as the web — a phone approval is the same decision made sooner, not a lighter-weight side door. In practice this is what keeps chains honest: the moment approving properly is slower than approving informally, informality wins. On the phone, properly is the fast option.
What happens to requests already in a chain when we change it?
In-flight requests complete under the chain they started in; the new rules apply to what is raised after the change. Rewriting the route under a request mid-journey is how an approval ends up that nobody's policy — old or new — would have produced, and it is the kind of ambiguity that surfaces later in exactly the disputes approval chains exist to prevent.
See it on your own data
Fourteen days, no card. Load a handful of employees and judge it against how you work today.