Workflow Engine

Based on Flowable and BPMN 2.0: Approvals and business flows can be orchestrated—add sign, rollback, parallel processing, and timeout escalation with assignee resolution according to organizational rules

Engine Positioning

The workflow engine handles high-frequency approvals and cross-role collaboration for manufacturing enterprises: designated purchasing, quality nonconformance review, engineering changes, payroll lock, project changes, and more. Based on Flowable and BPMN 2.0, it supports serial, parallel, rollback, countersignature, and timeout strategies; task assignees can be determined according to roles, departments, superiors, department heads, and other rules, and can leverage the reporting relationships from the organizational engine.

With the form and permission engines, the flow is not a second directory: who can see a record, who can edit fields on a node, and whether a delegate has expired all sit on the same foundation. Design-time can help build or change flows and preview component permissions. Runtime can complete a review within that person's own permissions through the API. It does not skip node rules, and it does not take the decision away from the person.

Where It Fits

  • Approvals rely on offline signatures or IM, if overdue no one escalates, during audits the complete trail cannot be found, and responsibility is unclear.
  • Branching, parallel processing, rollback, and countersigning are not clearly represented in lightweight tools, and complex manufacturing processes (quality countersigning, engineering changes) cannot be implemented.
  • If the handler is fixed to an individual, any organizational adjustment process will largely fail, forcing repeated revisions of the workflow diagram during implementation.
  • The business flow and approval flow are disconnected, the document status is inconsistent with the process instance, resulting in 'the process has passed but the document is still a draft'.
  • There is no standard for agency or transfer handling, responsibilities cannot be clearly explained in the process logs, and there is a lack of evidence for compliance and accountability.

Capability Highlights

  • BPMN OrchestrationBased on Flowable and BPMN 2.0 for process definition and version management, it supports common patterns such as sequential and parallel gateways and human tasks. Complex manufacturing approvals can be expressed, rather than being squeezed into lightweight tools that only have 'approve/reject' options.
  • Handler AnalysisParse the handler according to rules such as role, department, supervisor, and department head, and update it with changes in the organization's appointment effective dates. This reduces situations where hardcoding individuals causes workflows to fail extensively when the organization is adjusted.
  • Add Sign / Rollback / TransferCommon collaborative actions in manufacturing approval can be configured and process traces are retained, meeting supplementary signing scenarios such as quality countersignature, engineering changes, and procurement designation, with responsibility traceable to individuals in the track record.
  • Timeouts and UpgradesNode time limits, reminders, and escalation strategies can be configured to reduce the situation where a document 'sits in someone's to-do list'; the escalation path is still subject to organizational and permission constraints to prevent it from being arbitrarily transferred to unrelated personnel.
  • Linked with form permissionsNode can constrain field editing; submit, approve, and reject align with the business state machine to prevent the process from progressing while the document status remains in draft or 'Effective'.
  • Case AuditProcess trajectories can be traced, service compliance audits and accountability tracking; the strategy for in-transit instances after redefining in the design state should be explainable, without silently rewriting historical handling records.

Works With Other Engines

Organization Engine

Rules for handlers such as superiors/department heads depend on reporting relationships and the effective date of the position; when the organization changes, the process still operates according to the rules rather than failing on a large scale.

Permission Engine

Who can see the document and who can change fields at the node should be consistent with functional/data permissions; long-term situations where one 'can approve but cannot view' should be regarded as a configuration defect.

Form Engine

Process attached to business forms; rejection and approval are aligned with the business state machine, and the approval conclusions are synchronized with the document status in a way that is explainable and auditable.

Dual Agents

Design-time helps build or change process definitions and can preview component permissions. Runtime helps complete reviews through the process API and does not go beyond that account's handling scope.

Typical breakpoints

BreakpointCommon causeControl lever
After the organizational adjustment, the process largely failedThe handler writes a fixed individualRule Analysis + Effective Date of Appointment
The process has passed but the document is still a draftBusiness status not linkedPass/Reject the driver state machine
No trace of co-signing and transferringStandard collaboration actions not enabledAdding signatures/rollback/transfer leave traces for auditing
Documents long pending tasksNo timeout upgrade strategyTime Limits, Reminders, and Escalation Path
After the revision, the behavior of in-transit instances is unclearVersion strategy undefinedContinue using the old version en route or formalize the migration rules
The parallel branch takes effect as soon as one side approvesGateway condition errorBPMN Parallel Convergence Rule Regression
External write-back triggers error nodeIntegrated events are not idempotentBusiness Key + Node Trigger Condition

Promotion and Acceptance

  • Sample three types of processes: non-conforming quality review, procurement changes, and project milestones, to verify the completeness of parallel, rollback, and additional signature trails.
  • The analysis result of the same document handler around the effective date of the job transfer complies with the rules; after the proxy expires, it will no longer appear in the candidate list.
  • Rejection/Approval/Withdrawal is consistent with business status, inventory, or order status, and can be interpreted in reverse.
  • Runtime can complete reviews within that person's own permissions through the API, and does not approve for someone else; operation logs can be traced to specific accounts
  • After the process definition is revised, the in-progress instance strategy should be documented in writing, and at least one in-progress order should be randomly checked.
  • The overdue escalation path can be demonstrated: the complete trajectory from reminder to escalation handler
  • Process definition revision records the BPMN version number and specifies the in-progress instance strategy in the release notes

Implement in stages

  • Phase One: high-frequency approval templates, handler rules, status linkage, traceable baseline
  • Phase II: Parallel/Joint Approval, Timeout Escalation, Additional Signing/Transfer, Integration with Business State Machine
  • Phase Three: Cross-product process connection, integration triggers, operational backlog management, and design phase revision strategies

Create a landing prompt

Quality nonconformance review, engineering changes, procurement approvals, outsourced material issuance approvals, payroll locking, project changes, etc., should preferably all go through Flowable so that audit trails are centralized. Parallel countersigning is common in quality and process countersigning and should clarify the approval ratio and veto power; timeout escalation should distinguish between 'remind SQE' and 'escalate to department head.' When linked with MES/WMS status, the process approval/rejection should drive the business status, rather than having both sides change independently.

When not to apply

  • Using a process engine to replace MES workstation scheduling or WMS wave algorithms—it orchestrates human review and collaboration, but does not replace execution algorithms
  • All business rules are crammed into gateway expressions with no documentation—complex rules should be combined with form status and integration backwriting
  • Asking the agent to approve for someone else is out of bounds — handling stays within that person's own permissions and is logged through the business API
  • Treat instant chat confirmations as a process substitute — key collaboration should still be auditable and replayable

Product Fit