How Low‑Code Platforms Design Flexible Workflows: From Train Tracks to Nodes

What Is a Workflow

Using a train‑transport analogy, a workflow is like the tracks that guide a train (the data) from a start station to an end station. Different tracks represent alternative routes, and stations represent task nodes.

Design Considerations

Forms are the train cars, data are the cargo – forms must adapt to industry‑specific data types.

Stations are task nodes – basic stations include start and end nodes; complex stations can be sign‑off nodes (parallel or sequential), automatic nodes (e.g., RFID gates), gateway nodes, or temporary insert nodes.

Each node’s function depends on the characteristics of the cargo, mirroring how low‑code platforms must handle diverse industry requirements.

Low‑Code Platform Process Design

Popular open‑source workflow engines such as Activiti, Flowable, and Camunda focus on BPMN standards and offer limited support for free‑flow scenarios. Typical technical solutions include dynamically modifying the runtime flow or recompiling source code, both of which are costly and error‑prone.

A low‑code platform should provide simple, controllable support for free‑flow nodes, be distributed, and separate business logic from flow control.

The architecture consists of three main components:

flow – implements business logic;

process – handles flow control and parsing;

event center – publishes boundary events for external listeners.

Distributed transaction coordination (TC) ensures data consistency across services written in Go.

Node

Nodes are the basic, stateless resources of a workflow. By combining different node types, a specific business process is formed. Each node has attributes such as id, type, name, nextNodeId, and assignee, and implements interfaces for entry, exit, and core logic.

A node factory dispatches node creation and allows new node types to be added without altering the core engine.

Model

The model stores meta‑information of the workflow diagram. It visualizes node combinations as a logical graph, similar to a linked‑list’s pointers, without carrying execution state.

Instance

An instance is a concrete execution of a model, analogous to a departing train. Tasks within an instance can be human‑assigned (assignee) or automated (service). Assignees can perform actions such as skipping nodes, inserting temporary nodes, rolling back, or transferring tasks.

Services emit events via the event center for actions like notifications or emails.

NodeInstance

During execution, temporary nodes become node instances, which are recorded per instance. After the process finishes, node instances provide a complete audit trail of the actual flow, including any ad‑hoc nodes added during execution.

Execution

Executions represent branches in the workflow. The main executionId is created at start; each branch creates a child executionId, forming a tree structure. Branch merge conditions (any‑reject or all‑reject) determine whether parallel branches continue or are cleared.

Event

Events facilitate communication within the workflow. Synchronous events carry dynamic variables (e.g., assignee, branch conditions) needed during execution, while asynchronous events are notifications such as process start, node entry, or node completion.

Summary

Low‑code workflow design combines fundamental elements—nodes, models, instances, executions, and events—to enable flexible, distributed process control. Supporting free‑flow operations (parallel, sequential, sign‑off, rollback, sub‑processes, etc.) remains an active area of exploration.