How to Build a Zero‑Code, Scalable Enterprise Approval Center

Background

As enterprises digitize, approval workflows become a core OA function. Traditional manual approval is inefficient, and existing tools like DingTalk cannot integrate with internal systems or support diverse user bases, prompting the need for a zero‑code, seamlessly integrated approval platform.

System Features

Pre‑research

We evaluated the open‑source BPM engine Activiti, which implements BPMN2.0, offers visual process design, and supports condition nodes and approvers, but its integration with internal user directories is costly.

Approval Center Requirements

The system must provide powerful visual design, flexible form mapping, and support multiple internal scenarios. Key characteristics include:

Rule Engine : One‑stop development across devices; changes require only business flow adjustments.

Zero‑Code Development : Drag‑and‑drop reusable controls generate visual pages.

Multi‑Client Support : Works with internal SPA, CRM, DingTalk, and mobile apps.

Data Export : Export selected approval data.

Business System Event Consumption : Approval state changes can be subscribed to and transformed for downstream systems.

System Architecture

The solution consists of the following modules:

Form Module : Drag‑based form generation.

Process Module : Visual workflow configuration with conditions, approvers, and copy‑to fields.

Multi‑Client User Module : Aggregates user identities from various internal systems for approval routing and notifications.

Status Flow Module : Handles initiation, approval, rejection, and re‑submission.

Custom Display Component : Enables configurable display components without code.

Approval Automation Module : Maps form data to business systems via synchronous validation or asynchronous subscription.

Search Module : Leverages Elasticsearch for complex queries.

Main Module Details

Form Module

Forms are built from reusable components rendered by a unified engine. Key Q&A:

Q1: How are components aggregated? A1: Each component defines an aggregation type that determines compatible components (e.g., detail components can combine with any non‑detail component).

Q2: How to support dynamic show/hide? A2: User selections trigger events that toggle visibility of linked components.

Q3: How are visual components parsed? A3: Each component produces a JSON definition collected by the form engine.

Components are classified as library controls (developer‑implemented) or custom controls (configurable by operators). Component attributes include global business properties (visibility, required, editable) and basic behaviors (display fields, render mode).

Process Module

Inspired by Activiti’s graphical design, we adopted AntV G2 for visual workflow creation, offering simplicity, full visual encoding, and extensibility. The workflow abstracts modules for initiator, approver, copy‑to, conditional branches, and conditions, producing a B‑tree structure traversed by DFS to resolve approvers and copy‑to users.

Status Flow Module

The core states are initiation, approval, rejection, re‑submission, and duplication, each triggering notifications, task updates, and automation events. Activiti’s multi‑instance and end‑event features power the state engine.

Search Module

Elasticsearch indexes approval content, enabling complex queries while ensuring data consistency through local transaction tables, compensation jobs, and distributed locks.

Internal Business Integration

Multi‑Client User Module

A unified interface aggregates personal, organizational, role, and position identities, using a composite wf_user_id to avoid ID collisions.

Custom Display Component

To avoid hard‑coded integrations, custom display components consist of permission control, field mapping, request configuration, and value transformation, allowing concurrent API calls and format conversion for enums or timestamps.

Business Automation Integration

Form component IDs are mapped to business keys via a configuration layer, supporting both synchronous callbacks and asynchronous Kafka events for downstream systems.

Security Module

Four permission checks protect data: approval‑specific access, component data queries, custom synchronous validation, and asynchronous validation via callbacks.

Conclusion

Enterprise OA approval software has evolved to zero‑code form and workflow configuration with seamless system integration. Over three years, the approval center has served more than 2 million requests, yet manual development remains for component permissions and business attributes. Future work aims for fully zero‑code customization and continued optimization based on internal and external feedback.