Your Approval Process Is a State Machine Nobody Was Paid to Build

Problem

Most small teams don't lack an approval process. They lack a system to run it on.

In a 30-person team, asking for leave usually works like this. An employee posts a message in the department group chat. The manager replies "ok" if they see it, and if not, the employee posts again. An admin adds a row to a shared spreadsheet: name, dates, approved. A purchase follows a similar path, with a verbal check to the department head first.

A month later, when someone asks whether last month's purchase was approved, the answer is digging through chat history.

The status of every request lives in people's heads and in scattered messages. The rules live there too: leave under three days goes to the department manager, over that adds a director; purchases above a certain amount go to finance. When a rule changes, it is re-announced by word of mouth, and anyone who missed the message keeps initiating requests under the old rule.

And there is nothing to audit. Who approved what, how long it took, and where a request got rejected is recorded nowhere, except in the memories of the people involved.

Why it happens

Strip away the group chats and the spreadsheets, and an approval flow is a small system.

It has a state machine: pending, approved, rejected, withdrawn, CC'd. It has conditional branches: short leave takes one path, long leave another; small purchases stop at the department, large ones go to finance. It has notifications: the initiator, every approver, and everyone CC'd all need a reminder. And it has records: who did what, when, and what the outcome was.

If you build that system yourself, you write the state machine, the notifications, and the logs. And every rule change — a day threshold, an amount tier, an added approval level — means a code change, a redeploy, and another round of re-announcement to the whole team.

For a team of five to fifty people, that is a project nobody wants to fund. It is too small to justify a dedicated build, and too complex to hold in people's heads. Off-the-shelf SaaS options usually assume a multi-tenant cloud and an organization larger than yours. So the flow stays where it started: in chats and spreadsheets, running on human memory.

An approval process is not a small thing. It is just small enough that no one budgets for it.

The foundation

GewuMind Boot is a low-code backend foundation for enterprise admin backends, self-hosted on your own server with all data in your own MySQL 8. It is not a multi-tenant SaaS; it is a foundation your team installs and runs. Its core source code is open source under the Apache 2.0 license.

The workflow engine is built in, not bolted on. It covers the parts an approval flow actually needs:

Conditional branches — the route a request takes is decided by conditions, not by someone's judgment.
CC nodes — inform a person or department for record-keeping without putting them on the approval path.
Layer-by-layer rejection — a rejection can send the request back step by step, deny it outright to terminate the flow, or resubmit it to a previous node.
Per-node grouped approval forms — each node carries its own approval form.
Self-approval guard — if the initiator is also the approver of a node, the engine skips that node automatically, so nobody approves their own request.

Around the engine, the platform handles the parts an approval system quietly depends on.

The message center splits in-app messages into system, announcement, and todo. A bell icon shows the unread count, and a todo item jumps straight to the page where you handle it. The workflow adds a "my pending tasks" list you can filter, an "initiated by me" list, the full transfer history of each request, and withdrawal by the initiator.

Reporting ships with multiple preset report types — list, crosstab, conditional formatting, multi-sheet, merged rows — plus export. The dashboard shows stat cards, trends, and operation activity. Operation logs record key write operations: user, time, IP, and rows affected; login logs record logins. After a request is approved, the approval is traceable in these logs.

Authorization works in three layers — menu, button, and API — with the organization modeled as a company and department tree, so different roles see different menus, buttons, and endpoints.

And you do not start from an empty flow canvas. Ready-to-run demo processes ship with the platform: leave approval, purchase approval, contract approval, cross-department application, and expense reimbursement.

Example

The leave approval demo is a good cross-section of how a small team's flow runs.

An employee fills in the leave type, the number of days, and the reason, and submits. The request lands in the department manager's pending list. A conditional branch takes over from there: if the leave is over three days, a director-level step is added; within three days, the flow continues directly. When the request is approved, it is CC'd to HR for record-keeping — HR is notified, but never sits on the approval path.

The point is where the rule lives. The "over three days" condition is written in the flow definition, not in the manager's head. If the threshold changes from three days to five, you change the definition, and the engine handles the rest — no re-announcement to the team, no manager working from an outdated rule.

The purchase approval demo runs on amount-tiered routing: the request goes through the department first, and above the threshold it is routed to finance or a higher level automatically. Different amounts take different paths, without anyone making the call by hand.

The contract approval demo chains multiple roles in sequence. The cross-department application demo shows layer-by-layer rejection in action: a rejection at a later level can send the request back step by step, end it outright, or send it back to a previous node. An expense reimbursement demo ships as well, and in every one of these flows the engine skips a node if the initiator happens to be its approver.

After a request finishes, everything is in the system: the transfer history, the operation logs, and reports you can export. Next quarter, when someone asks how many requests were approved and who signed off, the answer comes from a report, not from a chat log.

What to look for

Before you adopt a workflow foundation, check the boundaries.

How are flows defined? GewuMind Boot is not a drag-and-drop BPMN designer. Flows are defined in definition files — nodes, routes, and forms — and changed as configuration. If your team expects a visual designer, note the difference up front.

How do notifications arrive? There is no built-in WeChat, DingTalk, or Slack integration. Notifications go through the in-app message center — the bell and the todo list — and, in the advanced edition, optional realtime channels such as SSE and WebSocket. If your approvers live in an IM app, plan for that.

Where does the data go? The system is self-hosted: your own server, your own MySQL 8, not a multi-tenant SaaS. If you want a hosted, multi-tenant product, this is not it.

What still requires development? Highly customized pages and complex third-party integrations still need development capability. What the platform takes over is the common part — approvals, messages, permissions, records, and reports — while your team keeps building the business-specific part.

Licensing is the item to read twice. The core source code is Apache License 2.0. Some advanced enterprise capabilities, including the workflow engine and the realtime push channels, are enabled via an offline License key. Unlicensed installs get a 30-day free trial. The official position is "free to start, upgrade as needed." Do not read "open source" as "the workflow is completely free." If your team plans to run approvals long-term, confirm the licensing mode before the trial ends.

Three quick questions before you adopt: can you express your three most-used flows in the demo definitions? Are your approvers actually in the app, or will you be fighting your team's chat habits? And who owns the flow definitions after launch?