SKIP TO CONTENT
A/L
SYS_008LAB

Workflow Engine

Node-Based Business Process Modelling

Approval chains and operational processes modelled as configurable graphs instead of hardcoded if-statements.

TYPE
AUTOMATION
STATUS
LAB
YEAR
—
ROLE
Architecture, experiment
PLATFORM
Node.js service, Flutter Web editor
STACK
Node.js · TypeScript · PostgreSQL · Neo4j
01

PROBLEM

Every ERP accumulates process rules: this discount needs a manager, that purchase over a limit needs two approvals, this stock issue needs a store keeper acknowledgement. Written as code, each new rule is a release, and each customer wants a slightly different rule.

The rules also become invisible. Nobody can see the approval chain, only discover it by hitting it.

02

SYSTEM

Processes are modelled as a graph of nodes — trigger, condition, approval, action, notification — persisted as configuration rather than code, and executed by a single engine.

Because the process is data, it can be shown as a diagram, versioned, and differed between tenants. A running instance keeps its own state, so a rule change does not corrupt work already in flight.

03

CORE FLOW

How the operation moves through the system.

ARCH_01 / NODE EXECUTION MODEL
  1. A business event from any product: bill created, stock issued, tour closed
  2. Evaluated against the event payload and tenant configuration
  3. Routed to a role or a person, with escalation and timeout
  4. Calls a domain operation idempotently; failures are retriable
  5. Outcome delivered to the people who need to know
  6. Full instance history: what fired, who decided, what changed
SELECT OR HOVER A NODE FOR DETAIL

Node execution model running from trigger through condition, approval, action, notification and audit.

04

KEY MODULES

M01Process editor
Visual node graph; the configuration is the diagram.
M02Execution engine
Instance state machine with retry, timeout and escalation.
M03Versioning
Running instances stay on the version they started on.
M04Audit
Per-instance history of every evaluation and decision.
05

ARCHITECTURE

Definition store
Process graphs held per tenant and versioned.
Graph exploration
Neo4j used to reason about dependencies and reachability in a process.
Instance state
PostgreSQL; each instance is durable and independently resumable.
Status
Laboratory work. Being proven against real approval chains before use in production.
06

ENGINEERING

The parts that were not obvious, and what the system does about them.

  1. 01 / 02

    Changing a process while instances are running

    Editing an approval chain must not strand a purchase order halfway through. Instances pin their definition version, so a change applies only to work that starts after it.

  2. 02 / 02

    Actions that must not run twice

    A retried action node cannot post the same journal entry again. Every action carries an idempotency key derived from the instance and the node, which makes retry safe by construction.

07

SCREENS

  1. SCREEN_01Process editor — node graph
  2. SCREEN_02Instance audit history
08

RESULT

An experiment with a clear target: the next customer-specific approval rule should be configuration, not a deployment.