Workflow & Approval Engine

Policy–system drift is the governance killer

Almost every organisation has a delegation-of-authority matrix. A document, approved, circulated, and — this is the important part — enforced by nothing.

So the matrix says one thing and the system enforces another, or enforces nothing at all. Purchase orders route by whoever is in the workflow rather than by value. A disposal below net book value gets the same approval as one above it. A budget transfer between departments takes the path that a single department’s transfers take. None of this is anybody’s fault, and all of it is invisible until an auditor arrives and asks for the evidence that the matrix was applied.

The engine’s only job is to close that gap: make the documented matrix the operating reality, and keep it that way when the matrix changes. Because it will change, and the second-order failure is worse than the first — an organisation that has to raise a development ticket to change an approval threshold will simply stop changing them, and the matrix will drift away from the business quietly, for years.

What the engine actually has to do

• Amount thresholds, and the conditions that escalate regardless of amount. Route by value, which is the easy part. But the useful part is the conditional branch: a disposal below net book value, a sale to a related party, a transfer that crosses departments, a purchase from a vendor with an expired trade licence. These escalate whatever the amount, because the amount was never the risk. A system that can only route on value is a system that will approve the thing you were most worried about, correctly, at the lowest level.

• Sequential and parallel are different tools, and the difference is who is waiting. Sequential approvals stack delay: each approver waits for the last. Parallel approvals collect opinions at once. Most organisations default to sequential everywhere because it feels more controlled, and then wonder why a purchase order takes eleven days. Use sequential when a later approver genuinely needs the earlier decision. Use parallel when they do not — which is more often than the org chart suggests.

• Segregation of duties, enforced structurally. Requester, approver and recorder as three different people, enforced by configuration rather than by vigilance. Vigilance fails on a Friday afternoon when someone is being helpful and the person who should approve it is on leave. Configuration does not, and that is the entire argument for putting it in the system rather than in a policy.

• SLAs, escalation, and delegation-on-absence — because the real failure is silence. An approval does not usually get rejected. It sits. The approver is on leave, or in a meeting, or has four hundred emails, and the request ages in a queue that nobody is measuring. An engine that escalates on an SLA and delegates on absence turns that silence into a decision — which is a governance improvement disguised as a convenience feature.

• And the workflow rules are themselves governed. Who changed the threshold, when, and why. Versioned, approved, auditable. Otherwise you have solved policy–system drift by creating a system whose rules can be quietly edited by whoever has admin rights — which is the same problem, wearing a better costume.

How Zepth runs approvals

One engine, behind every approval in Core, Vector and Edge — purchase orders, budget transfers, capital proposals, disposals, NCR dispositions. Which means one audit trail, in one shape, rather than five subsystems each with their own idea of what an approval record looks like.

The visual builder means the delegation of authority is configured by the people who own it. Bottlenecks are measured, not felt. And every approval carries its chain, its timestamps and the evidence behind it — reproducible years later by somebody who was not there, which is the only test an auditor actually applies.