Approvals

What this achieves

Approvals is where work waiting on a decision arrives, and where you define the routes that decide who is asked. It replaces the chain of emails a request would otherwise travel down, and leaves a record of who approved what.

The inbox and the engine

The section is two things. Most people only meet the first.

Option	Description
The task inbox	Where approvers act. One list of everything waiting on you, with the context needed to decide, and flags for anything overdue. Actions include approve, reject, escalate, and defer, individually or in bulk.
The workflow engine	Where administrators define how requests route. Configured once, then applied to every request of that kind.

Example: Olivia Bennett opens her inbox and sees a leave request and a training request together, rather than hunting through two sections for them.

What a workflow is made of

A workflow is a graph of nodes rather than a fixed list of approvers, which is what lets a route branch instead of running in one line.

Option	Description
Approval	A person or role is asked to decide.
Auto-approval	The request passes without a human, where your rules allow it.
Condition	The route branches on the request’s own details.
Notify	Someone is told, without being asked to decide.

Example: a training request at HC Corp under an agreed cost can auto-approve, while one above it branches to Daniel Okonkwo in Finance. That is one workflow with a condition, not two processes.

Parallel approvals

Several approvers can be asked at once, and you choose what finishing means: everyone must approve, or any one approver is enough. The join is outcome-aware — the first rejection can end an all-must-approve branch immediately, and the first approval can complete an any-one branch, cancelling the siblings rather than leaving them waiting.

Deadlines, escalation, and reminders

Each node can carry a deadline. Humavera detects a breach, sends reminders before the deadline, and escalates to a manager or a fallback approver when one passes.

Example: if a request sits unactioned while Olivia Bennett is away, it escalates rather than waiting indefinitely for her.

Delegation and separation of duties

Routing honours active and out-of-office delegations, and records that the delegate acted rather than silently showing the original approver’s name.

Separation of duties is enforced: an approver who is also the initiator is blocked and the task is escalated to a safe fallback, with the block audited. This is why the person who raises a request cannot quietly approve it themselves.

Versioning and simulation

Published workflow versions are immutable, and a request already in flight stays locked to the version it started under. Changing a workflow does not rewrite the route a pending request is following.

You can also dry-run a workflow against sample data. The simulation writes nothing and shows the path a request would take and who would be asked — which is how you check a change before it reaches real requests.

When nothing is configured

If no workflow is bound to a feature, it falls back to its own built-in approval path. A workflow error also fails safe, so core approvals are never blocked by a configuration problem.

What happens next

Approved outcomes land in whichever section owns them: an approved leave request updates a balance, an approved backfill becomes a draft requisition, and an approved pay run can be finalised. Workflow analytics report where routes stall and which nodes breach their deadlines, and any instance can be exported as a human-readable audit document.

This section also holds work that is tracked to a conclusion rather than routed for a decision. A compliance question, an audit finding, or a dispute is opened as a case with its evidence kept beside it — see Work a governance case.