Workflow systems · principle
Approval Rules as Data, Not Code: How Flexible Approval Workflows Are Built
Build an approval workflow by keeping its rules as data, not code. Who may submit a request and who approves it are set per category, project, author and amount range in a rules table, so they can be changed without a release. Add an append-only audit log enforced by the database, and every decision stays traceable.
01The problem with rules in code
In many systems the approval route is hard-coded: if the amount is over a threshold, send it to this person. Every change in the organisation, a new project, a new approver, a different limit, becomes a developer task and a release. The rules change often; the code should not.
02Rules as data
| Rule dimension | Example |
|---|---|
| Category | Travel, equipment, services |
| Project | Different approvers per project |
| Author | Who may submit this kind of request |
| Amount range | Different approvers above and below a limit |
An administrator edits the rules, the engine reads them, and the next request follows the new route. No deployment is involved.
03What makes it safe
- Append-only audit log enforced at the database level: entries can be added, never changed or removed.
- Per-request encryption for sensitive content.
- Tests around the rules engine, so a change to the rules cannot silently break routing.
04How a request moves through the rules
- Submit. The author files a request with a category, a project and an amount.
- Match. The engine looks up which rule applies to this combination; the most specific rule wins.
- Route. The approvers named by that rule are asked, in order or in parallel, as the rule says.
- Decide. Each approval or rejection is written to the audit log with who, when and why.
- Change safely. When the organisation changes, an administrator edits the rule; the next request follows it, and old decisions keep the rule that applied at the time.
That last point is easy to miss. A decision should always be explainable by the rules in force when it was made, which is another reason to store rules as versioned data and not as branches in code.
05A note on this example
This is a personal project, not a production system. It demonstrates how I design flexible rules, the audit trail and the testing around them.
FAQShort answers
- Why keep rules in a database instead of code?
- Rules change with the organisation. As data, they can be updated by an administrator immediately and without a release.
- What is an append-only audit log?
- A log where entries can only be added. Enforcing it in the database means even application bugs cannot rewrite history.
- Can the rules depend on the amount?
- Yes. Amount ranges are one of the dimensions a rule can use, together with category, project and author.
Have a task like this? Write to me.