How Low-Code Platforms Transform Workflow Development: Inside Baidu’s Engine

1. Traditional vs Low-Code Process Development

Low‑code platforms have evolved from simple front‑end component drag‑and‑drop tools into complete front‑back‑end integrated business‑building platforms. Process‑centric scenarios such as approval and business flows have become the most demanding use cases.

There are few articles that discuss the details of workflow engines, and most developers view low‑code workflow engines as a black box.

This article walks through "Traditional Mode and Low‑Code Mode Process Development – Principles Behind Low‑Code Workflow Engines – Visual Process Editor Details – Runtime Engine Details" to share Baidu Cloud Low‑Code team's research results and thoughts, presenting a full view of a low‑code workflow engine.

1.1 Traditional Mode: Manual Development of a Process

We illustrate a simple "Material Borrowing" process as shown in Figure 1.

Figure 1: Simple "Material Borrowing" process

The process consists of the following functional points:

A form page for submitting material borrowing requests.

A pending notification sent to the approver.

A handling page where the approver can approve or reject.

After approval, inventory is deducted and database records are updated.

Process end marker logic.

1.1.1 Manual Development Steps

To implement the above requirements in a traditional development mode, the workflow is built manually through four steps: front‑end and back‑end task breakdown, independent development by front‑end and back‑end engineers, sandbox integration testing, and production deployment.

Figure 2: Manual development workflow

1.1.1.1 Front‑End and Back‑End Task Breakdown

Front‑end engineers need to deliver three pages: request form, pending notification, and approval page. Back‑end engineers need to provide four APIs: submit form, fetch pending notification content, fetch pending list, and approval action.

1.1.1.2 Independent Development

Front‑end developers typically use a framework (React/Vue) and a UI component library, plus a mock service for API simulation. Back‑end developers use a local or in‑memory database, write business logic, and perform unit testing.

1.1.1.3 Sandbox Integration

Both sides deploy code to a sandbox environment for joint testing and resolve issues.

1.1.1.4 Production Deployment

Prepare production machines, migrate databases, and package code for release.

Thus, traditional development requires coordination among many parties to deliver a functional workflow.

1.2 Low-Code Mode: Developing the Same Process

Low‑code solutions aim to reduce labor and communication costs, simplifying functional development. Using Baidu Cloud’s low‑code platform "AisuDa" (https://aisuda.baidu.com/), we recreate the material borrowing workflow, demonstrating how the low‑code engine reduces development complexity.

Development in AisuDa can be divided into three main steps: creating data models, designing the process with the visual editor, and building the submission form.

Figure 3: Low‑code development of the workflow

1.2.1 Data Model Creation

Two tables are needed: "Material Borrowing Records" to store user requests, and "Material Inventory" to store current stock information. These tables are created via AisuDa’s visual modeling interface.

Figure 4: Required data tables

The visual modeling allows front‑end developers with basic database knowledge to design and create tables without back‑end involvement, and to separate data for development, testing, and production environments.

1.2.2 Process Design with Visual Editor

When a user submits a borrowing request, a new record is added to the "Material Borrowing Records" table, triggering the process. The editor is configured to start the workflow on record insertion, display the request details on the approval page, and decrement inventory upon approval.

Figure 6: Process design in the visual editor

The editor also supports querying the current inventory and updating it with a "‑1" operation using a formula editor.

Figure 7: Query current inventory and decrement by 1

Figure 8: Formula editor for data linkage

1.2.3 Building the Submission Form

A "model form" component is dragged onto a page; it automatically generates form fields based on the data model, eliminating manual UI and API development.

Figure 9: Model form bound to "Material Borrowing Records"

Figure 10: Form fields generated according to model definitions

1.2.4 Publishing the Application

Clicking the "Publish" button deploys the workflow to the online environment, where a SaaS architecture centrally manages the production deployment.

Figure 11: Publishing the workflow application

1.3 End‑User View of the Deployed Application

The final application includes a request form, a centralized pending notification center, an approval detail page, and automatic inventory deduction after approval.

Figure 12: Model form for material borrowing request

Figure 13: Centralized pending notifications

Figure 14: Approval detail page

Figure 15: Inventory before approval

Figure 16: Inventory after approval (decremented)

2 Principles and Design of the Low‑Code Workflow Engine

We previously compared traditional and low‑code development steps, highlighting how low‑code saves labor. The engine consists of two parts: a visual process editor for designing workflows and a runtime engine that executes them.

2.1 Visual Process Editor

The editor provides a node‑and‑edge interface. Supported node types include human nodes, gateway nodes, automatic nodes, and start events, covering the core capabilities of a generic workflow engine.

Figure 17: Visual editor linking database and application data sources

Figure 18: Full editor UI with node palette

2.1.1 Drag‑and‑Drop and Save

When the user drags nodes, the editor updates a JSON configuration representing the workflow. Clicking "Save" sends the configuration (including nodes and lines) to the backend.

Figure 19: Workflow definition data structure

2.1.2 Assigning Processors to Human Nodes

Processors can be defined by organization (department, role, etc.), expressions (e.g., "process initiator"), or hierarchy (supervisor). This flexibility ensures that changes in personnel only require updates to the organization directory, not the workflow definition.

Figure 20: Approver node with processor configuration

2.1.3 Node Data Access Permissions

Each node can be granted specific field permissions (e.g., view‑only for approvers). This prevents unauthorized data modifications during the process.

Figure 21: Setting "view" permission for an approval node

Figure 22: Detailed configuration of the "view" permission set

2.2 Runtime Engine

The engine retrieves the saved workflow definition from the database when a process is triggered, then drives the execution according to node types and configurations.

2.2.1 Engine Overview

Figure 23: Runtime engine architecture

2.2.2 Process Trigger

Triggers can be form events, entity (CRUD) events, or direct API calls. The article focuses on entity‑event triggers, where inserting a record into a bound data model automatically starts the workflow.

Figure 24: Flow data table schema

Key fields include definition (workflow definition), data (submitted form data), active_nodes (current node IDs), and status (process state).

2.2.3 Process Flow

When a workflow is triggered, a new record is created in flow_data, copying the definition and input data. Active nodes are inserted into flow_node. For each eligible processor, a separate flow_node entry is generated, and the active_nodes field is updated.

Figure 25: Flow node data table

The front‑end "My Tasks" view queries flow_node for records where the current user is the processor, displaying pending tasks.

Figure 26: Pending task list derived from

flow_node

2.2.4 Process Completion

When the workflow reaches its final node, the engine updates the status field in flow_data to indicate completion, allowing users to view finished processes.

3. Conclusion

The article reveals the principles behind low‑code workflow engines, demonstrating Baidu Cloud’s "AisuDa" solution and its ability to simplify complex business scenarios. Low‑code workflow engines are rapidly evolving and already solve many real‑world problems.

- - - - - - - - - - END - - - - - - - - - -