Approval workflow

Almost every business system is a workflow system underneath. A record is raised, someone checks it, someone else authorises it, and at each point the question is the same: who is allowed to see this, who is allowed to act on it, and what happens if nobody does.

The workflow module answers that as configuration rather than code, which is why the same engine serves a regulator’s licensing queue, a hospital’s requisition approvals and a diocese’s remittance sign-off.

Statuses and routing

Work moves through named statuses, each defining where it can go next. A status can fan out to several possible destinations - approve, query, reject, escalate - and the options presented to a user are the ones their role actually permits.

Because the route is declared rather than written, changing an approval chain is a configuration change reviewed by the people who own the process, not a release.

Assignment and visibility

Statuses can be assignment-enabled: an item in that status is visible only to the person it is assigned to. Other statuses stay visible to anyone whose role grants access.

That distinction matters more than it first appears. It is the difference between “the finance team can see all pending items” and “this item is with a named officer, and nobody else needs to be looking at it”. Both are legitimate; a deployment chooses per status.

A supervisory capability exists for the cases that need it - a manager who must see items assigned to their team without becoming an approver. It is granted deliberately rather than assumed.

Separation of duties

Two controls exist because auditors ask for them:

No self-approval in succession. A status can require that whoever moved an item into it cannot be the one to approve it out again. This closes the loop where a single person advances work through several stages unchecked.

Privileged override with a record. Where an organisation genuinely needs a senior person to override that rule, they can - after an explicit confirmation, and the override is recorded. A control that cannot be overridden gets worked around outside the system, which is worse.

Escalation and reminders

Two time-based behaviours, configured per status:

• Reminders notify the responsible person after a defined period without changing anything.
• Escalation moves an item to a different status once it has sat too long - to a supervisor, a committee, or a queue that gets watched.

Together they answer the question that sinks most manual approval processes: what happens when someone is on leave.

Notifications

Notification follows responsibility. Email goes to the person an item is assigned to, once it is assigned - not broadcast to a group in the hope that someone acts. Deployments that do not want email at all can switch it off centrally.

There is also a notify-only role: stakeholders who should know an item has moved, without being able to open or act on it. Useful for audit and oversight functions that should observe rather than participate.

What you get in the interface

• A dashboard of items awaiting the signed-in user
• The full history of an item - who moved it, when, from which status to which, with any note
• Filtering by status, assignment, date and the fields that matter to the deployment
• Bulk action where the process genuinely permits it

Where it fits

Workflow is shared infrastructure rather than a feature of one module. The same engine routes financial approvals, document sign-off and case management, so an organisation configures its hierarchy once.

Workflow events are a natural subscription for webhooks - an approval granted or an item escalated is exactly the sort of thing a downstream system wants to know about without polling.