In the previous post about permissions, I ended with one judgment:
Permissions define boundaries. Workflows define how business moves forward.
This post continues with the workflow engine.
When many people hear "workflow", their first reaction is approval flow.
Leave approval, reimbursement approval, contract approval, purchase approval. Draw a few nodes, configure approvers, add a few conditional branches, and it feels like the workflow engine is finished.
I used to think this way too.
But after building a low-code platform, I realized that a workflow engine is far more than drawing approval flows.
It has to answer a deeper question: can the platform stably describe, execute, and trace the entire process of a business record from creation, submission, review, rejection, modification, completion, and then onward into automation and data changes?
In other words, the workflow engine is not an isolated feature. It is part of the business runtime.
A workflow is not a diagram, but state change
The most visible part of a workflow designer is the diagram.
Start nodes, approval nodes, conditional branches, copy nodes, and end nodes.
These shapes matter because users need them to understand the business path.
But for the system, the truly important thing is not the diagram. It is state change.
A contract moves from draft to under approval, then to legal review, finance review, approved, rejected, and archived. These state changes are what actually happen in the business.
If a workflow stays only at the diagram level, a problem appears:
The diagram may look beautiful, but data state, permissions, notifications, logs, and downstream automation are not really connected.
So I prefer to understand workflow as a state machine.
Nodes are states.
Lines are state-transition paths.
Approval actions are triggers for state transition.
Workflow records are the history of state transition.
With this design, workflow is no longer only about who approves. It is about which state a business object enters under which conditions.
Workflows must bind to business objects
Workflows in a low-code platform cannot exist apart from the data model.
If a workflow is only an empty approval template, it is hard for it to truly enter the business.
A workflow must bind to a specific business object.
Contract approval binds to the contract table.
Expense reimbursement binds to the reimbursement table.
Purchase requests bind to the purchase request table.
Project initiation binds to the project table.
Once bound, the workflow can read business fields.
What is the contract amount?
What is the customer level?
Which department submitted the request?
What is the project budget?
Does it involve an external vendor?
These fields decide how the workflow moves.
For example, if a contract amount is below 100,000, it may only need department-lead approval. If it exceeds 100,000, it may also require finance review. If it contains special terms, it may require legal review.
This shows that workflows do not run in the air. They depend on the data model.
The clearer the data model is, the more stable workflow expression becomes.
Approvers should not be hard-coded
One easily underestimated problem in workflow design is the approver.
In simple scenarios, a specific person can be assigned directly.
But real enterprise workflows are rarely that simple.
The approver may be the initiator's direct manager.
It may be the head of the initiator's department.
It may be a role such as finance, legal, or procurement owner.
It may come from a form field, such as project owner, customer owner, or contract owner.
It may also change dynamically based on amount, region, or business line.
If approvers can only be hard-coded, workflows quickly lose flexibility.
So the workflow engine must support dynamic approvers.
This involves organization structure, roles, user fields, department fields, and rule expressions.
In other words, the workflow engine naturally depends on the permission system and organization model.
That is why I do not like treating workflow as an isolated module.
It appears to handle approval, but it is actually scheduling responsibility relationships inside the enterprise organization.
Conditional branches must not become black boxes
Conditional branches are also critical in workflows.
A branch may look like a simple judgment:
Amount greater than 100,000 goes to finance.
Customer level A goes to senior approval.
The R&D department goes to a technical lead.
An empty field returns for completion.
When there are only a few rules, this is fine.
But as rules grow, branches can easily become black boxes.
Users will ask:
Why did this request go to legal?
Why did it not go to finance?
Why was my request returned?
Why did two contracts with the same amount take different paths?
If the system can only answer "because that is how the workflow is configured", that is not enough.
I think the workflow engine should at least leave explainable execution records.
Which branch was hit.
Which fields were read during evaluation.
What the field values were at that time.
Which condition was true and which condition was false.
This information is extremely important for troubleshooting.
Otherwise, when a workflow goes wrong, the final answer is often that developers have to check logs, while business users cannot understand the process themselves.
Rejection is not simply going back one step
Many workflow engines have "reject" or "return" actions.
But returning is actually complex.
Return to the initiator?
Return to the previous node?
Return to a specified node?
After return and resubmission, should the workflow start from the beginning or continue from the returned node?
Which fields can be modified during return?
Should the return record be kept?
Are previous approvers' opinions still valid?
For example, in contract approval, legal may return the contract to sales to add terms. After sales modifies it, does it need to go through the department lead again? Does the previous finance review still count?
There is no single answer to these questions. It depends on the business.
So the workflow engine should not implement return as one fixed action.
It should be a configurable transition.
Where to return, whether to rerun previous steps, which fields can be opened for modification, and how previous approval opinions are handled should all enter workflow design.
Workflows change permissions
In the previous post about permissions, I wrote that workflows and permissions cannot be separated.
From the workflow perspective, this becomes even clearer.
For the same reimbursement form, permissions differ across workflow states.
In draft state, the initiator can edit it.
After submission, the initiator can no longer change the amount.
During department-lead approval, the approver can fill in approval comments.
During finance review, finance can modify the expense category.
After the workflow ends, ordinary users can only view it.
This shows that workflow nodes change field permissions and action permissions.
If the workflow engine is not connected to the permission system, temporary frontend controls become the only protection.
That is dangerous.
Users may bypass frontend restrictions through APIs, imports, automation, or AI.
So permissions on workflow nodes must become part of backend permission evaluation.
Where the workflow goes, permissions should follow.
Workflow is not only approval; it also includes automatic actions
In enterprise workflows, not every step should require human handling.
Many nodes should be completed automatically.
After contract approval, automatically generate a contract number.
After purchase request approval, automatically create a purchase order.
After project initiation approval, automatically create a task template.
When a customer stage becomes won, automatically notify the implementation team.
After reimbursement approval, automatically write into the payment plan.
If all these actions require manual handling, the workflow only moves responsibility from one person to another. It does not truly reduce work.
So the workflow engine must support automatic nodes.
Automatic nodes can update fields, change status, send notifications, create records, call APIs, execute scripts, or trigger automation.
This turns workflow from an approval tool into a business orchestration tool.
I think this is an important difference between a low-code platform and an ordinary approval system.
Workflow records matter more than workflow diagrams
A workflow diagram describes the design.
Workflow records describe the facts.
When an enterprise needs accountability and review, it looks at facts.
Who submitted at what time?
Who approved?
Who returned it?
What was the return reason?
Which conditional branch was hit?
What automatic action did the system execute?
Did the API call succeed?
How long did the workflow take?
How long was a certain node blocked?
This information is not only logs. It is part of business data.
If workflow records are incomplete, later statistics, audit, and AI analysis all become difficult.
For example, if managers want to know the average contract approval time, they cannot only look at the current contract status. They need the start and completion time of each node.
If AI wants to summarize "this week's approval bottlenecks", it also depends on workflow records.
So the workflow engine should design execution records from the beginning.
Adding them later is painful.
What matters most in the initial workflow engine
A workflow engine can easily grow very large.
BPMN, countersign, either-or approval, additional signing, transfer, withdraw, return, subprocesses, timers, message events, exception boundaries, compensation mechanisms...
All of these capabilities matter, but the initial version cannot swallow everything at once.
If I were building the initial version, I would first make sure of several things.
First, workflows must bind to data tables.
Workflows cannot be isolated templates. They must run around business objects.
Second, node types should be controlled at the beginning.
Start, manual approval, conditional branch, automatic action, and end should first make the main path work.
Third, approvers must support dynamic configuration.
At minimum, the platform should support specified members, roles, department heads, user fields, and the initiator's manager.
Fourth, workflow state must be written back to business data.
A business record should know whether it is in draft, under approval, approved, rejected, withdrawn, and so on.
Fifth, node permissions must enter backend permission evaluation.
Which fields are visible, which fields are editable, and which actions are executable cannot rely only on the frontend.
Sixth, workflow records must be complete.
Every submission, approval, return, and automatic execution should leave structured records.
Seventh, automatic nodes should first support the most common actions.
Field updates, record creation, notifications, and API calls are among the most practical actions.
After these capabilities are stable, countersign, additional signing, subprocesses, and more complex event mechanisms can be added gradually.
Common mistakes in workflow design
The first mistake is focusing only on the workflow diagram.
Drawing the diagram does not mean the workflow can truly run. State, permissions, records, and exception handling must all follow.
The second mistake is hard-coding approvers.
It is simple at the beginning, but once the organization changes, people move, and cross-department workflows increase, maintenance becomes very hard.
The third mistake is making return logic too rough.
Returning is not simply "go back one step." It affects data modification, approval opinions, and later paths.
The fourth mistake is separating workflow and permissions.
If node permissions do not enter the permission-evaluation system, workflow state can easily be bypassed.
The fifth mistake is leaving no records for automatic actions.
If the system automatically changes fields, creates records, or calls APIs without logs, problems become hard to investigate.
The sixth mistake is making the workflow engine too complex from the beginning.
A workflow engine can certainly be very complex, but the first version of a low-code platform needs stability, explainability, and extensibility more.
It is more important to make common enterprise workflows run steadily than to chase every advanced capability.
The direction
The workflow engine is a module that is very easy to misunderstand in a low-code platform.
On the surface, it draws processes and configures approvers.
But deeper down, it connects the data model, permission system, organization structure, automation, integration, and audit.
The data model tells the workflow what object it is handling.
The permission system decides what each node can see and change.
The organization structure decides who should take responsibility.
Automation makes the workflow more than human handoff.
Integration lets the workflow connect to external systems.
Workflow records make the business process traceable and reviewable.
So the workflow engine is not an approval plugin.
It is the track on which enterprise business runs.
For INFORMAT, the workflow engine is not about whether a user can draw an approval diagram. It is about whether business objects can move forward along clear, controllable, and traceable paths.
In the next post, I want to write about automation and the plugin mechanism.
Workflows define business paths. Automation and plugins define how the platform extends actions outward.
Top comments (0)