中国特色审批为什么不能只依赖 BPMN 标准元素？

中国特色审批不能只依赖 BPMN 标准元素，不是因为 BPMN 不能画审批流程，而是因为 BPMN 主要描述流程中的任务、事件、网关、顺序流和执行语义，并不负责定义企业组织关系、审批动作语义、表单权限、审计证据和动态改签规则。

正确的工程边界是：用 BPMN 2.0 表达稳定的流程骨架，用 Flowable 的多实例、任务 API、监听器和扩展元素承接引擎能力，再由 OA 审批领域服务实现会签、或签、加签、退回、撤回、转办、委托、抄送、数据权限和审计规则。只用标准元素，模型会迅速膨胀；完全绕开 BPMN，又会失去标准化流程语义和可视化能力。

资料核对时间：2026 年 8 月 1 日。本文以 OMG BPMN 2.0.2 规范、Flowable Open Source 当前公开文档及 2025.2 Javadoc 为依据。不同 Flowable 版本的扩展 API 可能变化，项目应以实际依赖版本为准。

一、核心结论与问题边界

BPMN 标准究竟解决什么问题

BPMN 是 Business Process Model and Notation 的缩写。OMG 发布的 BPMN 2.0.2 规范提供了业务流程的图形符号、XML 交换格式和一组执行语义，让业务人员、架构师和流程引擎能够围绕同一张流程图沟通。

它擅长回答这些问题：

• 流程从哪里开始、在哪里结束；
• 哪些任务由人处理，哪些任务由系统执行；
• 条件分支、并行分支和汇聚怎样发生；
• 定时、消息、信号、错误和补偿事件如何影响流程；
• 一个活动是否需要按集合顺序或并行执行多次；
• 子流程、调用活动和跨参与者消息如何组织。

BPMN 是流程控制语言，不是完整的 OA 产品协议。它没有统一规定“中国式会签”“前加签”“退回发起人”“撤回到上一节点”“转办后责任归属”这些业务术语，更不会替企业决定部门负责人、岗位层级、数据权限或电子签名规则。

标准 User Task 为什么不等于企业审批节点

BPMN User Task 表示需要人完成的工作。标准可以描述 humanPerformer 和 potentialOwner；Flowable 进一步提供 assignee、candidateUsers、candidateGroups 等实用能力。引擎到达用户任务后创建待办，用户可以领取并完成任务。

但企业审批节点通常还包含：

Flowable 官方 API 文档还特别说明，引擎不会在运行时验证分配的用户是否存在，因为它需要与 LDAP、Active Directory 或企业自己的身份系统集成。这恰好说明：组织和权限不是 BPMN 引擎可以单独解决的问题。

一张图看懂三层能力边界

图 1：BPMN 负责稳定控制流，Flowable 扩展负责执行接口，OA 领域服务负责中国特色审批语义。

三层并不是互相替代，而是逐层补充。最下层越标准，流程越容易交换和理解；中间层隔离引擎差异；最上层沉淀企业审批能力，避免每张流程图重复实现同一套规则。

二、关键概念与能力差异

会签为什么不能只画一个多实例节点

BPMN 多实例活动能够对一个集合逐个或并行执行任务。Flowable 文档说明，多实例会维护 nrOfInstances、nrOfActiveInstances、nrOfCompletedInstances 等变量，也可以用 completionCondition 在达到比例后结束剩余实例。这为顺序会签、并行会签和通过比例提供了良好基础。

但真正的会签产品还要回答：

• 会签人是在流程启动时确定，还是到达节点时按组织实时计算；
• 同一部门多人是否去重，岗位空缺时怎样降级；
• 达到 60% 是按人数、权重、部门还是层级计算；
• 弃权、超时、撤回意见和管理员代办怎样计票；
• 达到通过条件后，未办任务是取消、转抄送还是保留记录；
• 运行中加签后，分母和完成条件是否重新计算；
• 多轮会签如何区分轮次并汇总个人意见。

多实例解决“为集合中的每个元素创建执行实例”，会签服务解决“集合从哪里来、票怎样算、规则何时冻结、证据如何保存”。把两者混为一谈，测试环境里的三人会签能跑，生产中的组织变更、加签和重试就容易出错。

或签为什么不只是一个排他网关

或签通常表示多人中任意一人处理即可。最简单的实现是创建一个带候选人的 User Task，由其中一人 claim 并完成。这与“为每个人创建一个任务，再用网关判断谁先完成”不是一回事。

排他网关决定的是一条顺序流如何选择，并不负责候选人的抢占、领取、释放和身份校验。企业还可能要求指定主办人优先、候选人不可重复领取、领取后允许转办、超时自动释放、完成后给其他候选人发送已处理通知。这些规则属于任务服务和审批策略，而不是网关本身。

加签为什么会改变运行时参与者集合

加签是在流程已经运行后增加办理人。前加签要求新增人员先处理，后加签要求当前人完成后由新增人员处理，并行加签则可能改变当前会签集合。标准 BPMN 可以预先画出固定分支，却无法预知任意时刻、任意数量的临时办理人。

图 2：标准元素可以提供实现积木，但审批动作的完整语义仍需要领域策略、运行时命令和审计记录。

可靠的加签实现至少需要：

因此，加签不是“多画一个 User Task”，而是一条受策略控制、可追溯的运行时变更命令。

三、模型架构与运行机制

退回和跳转为什么容易破坏令牌语义

BPMN 顺序流天然描述令牌向前移动。为了退回，设计者可以显式画一条返回线，但每个节点都连接到申请人或上一节点后，流程图会出现大量回边，死循环和网关汇聚也更难验证。

另一种做法是使用 Flowable 的运行时状态变更能力，把活动实例移动到目标节点。它可以让图保持简洁，却不会自动回答这些业务问题：

• 退回到固定节点、上一办理节点还是任意历史节点；
• 并行分支是否全部撤销，其他会签人的任务怎样处理；
• 已完成节点的意见是否保留，重新审批是否生成新轮次；
• 流程变量、表单数据和附件是否回滚；
• 退回后按原办理人、最新组织还是重新选人；
• 边界定时器、子流程和补偿任务如何重建。

因此，ChangeActivityStateBuilder 一类 API 只是“移动执行状态”的工具。退回服务必须先计算合法目标和影响范围，再执行引擎命令，并写入完整操作记录。直接在业务代码里随意 moveActivityIdTo，等于绕过了审批策略层。

撤回和撤销为什么不是普通流程分支

撤回通常由发起人在流程运行中主动提出，操作者并不一定拥有当前任务。撤销还可能发生在流程结束后，要求业务单据作废或发起反向流程。它们都不是当前 User Task 上的一次普通完成动作。

系统需要判断时间窗口、当前节点、是否已经产生外部副作用、是否允许自动撤销，以及是否需要被办理人确认。已经调用 ERP、支付、电子签章或归档服务时，撤销往往需要补偿任务，而不是简单删除流程实例。

删除流程实例只能表示引擎停止执行，不能自动完成业务补偿、意见留存、通知回收和单据状态修复。企业应把撤回和撤销建模为领域命令，并明确正常结束、终止结束和人工删除的区别。

转办和委托为什么不能混成 setAssignee

转办通常意味着责任完全转移给另一人；委托通常保留原责任人，由受托人代为处理，之后可能 resolve 回原任务。两者在界面上都像“换个人”，审计和责任语义却不同。

Flowable TaskService 提供 setAssignee、delegateTask、resolveTask 等操作，但企业仍需要校验组织关系、授权期限、利益冲突、数据可见范围和审计原因。只调用一个 API 而不区分领域动作，会让已办记录无法解释谁承担责任。

四、核心场景与处理策略

抄送和传阅为什么不应伪装成 User Task

抄送是把审批结果或过程信息送给相关人，通常不阻塞主流程；传阅可能要求确认已读，但也不一定决定流程走向。如果把每个抄送人都建成 User Task，主流程会等待所有人完成，待办统计也会混入大量非办理任务。

更合理的做法是使用 wf_cc_record、wf_circulation_record 等业务记录保存接收人、发送原因、已读时间和权限快照，通过 Outbox 或事件投影异步生成消息。只有“必须确认后流程才能继续”的场景，才适合建成真正的用户任务或接收任务。

判断标准是：这个人是否拥有改变流程结果的办理权。如果没有，就不要为了在流程图上看见他而制造执行令牌。

表单、按钮和数据权限为什么属于另一个维度

同一个审批节点，不同角色看到的字段可能不同：财务可以编辑科目，部门负责人只能填写意见，申请人退回后可以修改金额，抄送人只能查看脱敏数据。BPMN 可以关联 formKey，却不会定义企业完整的字段级权限模型。

审批平台通常需要独立配置：

• 节点可见字段、只读字段、必填字段和隐藏字段；
• 同意、驳回、退回、转办、加签等按钮权限；
• 数据行权限、部门范围、租户边界和敏感字段脱敏；
• 附件上传、下载、删除和水印规则；
• 移动端、门户端和管理端的交互差异。

这些配置可以通过自定义 extensionElements 与 BPMN 节点关联，但真正的校验必须由后端权限服务执行，不能只相信设计器配置或前端按钮是否显示。

五、数据、规则与状态设计

为什么把所有规则都画进 BPMN 会导致模型爆炸

假设一个节点同时支持会签、前后加签、退回三个目标、转办、委托、超时升级和抄送。如果每种可能都画成网关、任务和回边，流程图会从业务主线变成产品实现细节图。

模型爆炸带来的问题包括：

• 一个普通审批节点被拆成十几个技术节点，业务人员无法审阅；
• 每次规则调整都需要重新部署流程定义；
• 网关表达式散落，难以统一测试和灰度发布；
• 回边、并行汇聚和多实例组合产生隐蔽死锁；
• 不同流程复制相同加签、撤回和权限逻辑，维护成本成倍增长。

好的 BPMN 模型应保留对业务有意义的里程碑和控制流，把通用审批动作收敛到平台服务。规则非常稳定、会影响主路径时画进 BPMN；规则动态、跨流程复用或主要影响交互时放入领域配置。

三层架构应该怎样落地

推荐采用“标准模型层、引擎适配层、审批领域层”三层架构。

自定义扩展建议保存声明式配置，例如 nodePolicyId、actionSet、formPermissionId、assigneeRuleId 和 returnPolicyId。不要在 BPMN XML 中写大量 Java 类名、SQL 或不可迁移脚本。引擎适配器读取配置后调用领域服务，领域服务再生成标准化命令。

六、工程实现与系统集成

一次审批动作应该怎样执行

图 3：审批动作先经过策略和权限校验，再调用 Flowable；操作记录、状态投影和通知由同一命令链路生成。

推荐的后端处理顺序是：

所有入口，包括 PC、移动端、开放 API 和管理员工作台，都应调用同一个命令服务。否则普通用户的退回会校验权限，管理员页面却直接改 ACT_RU_TASK，最终仍会出现不可解释的数据。

核心数据表应该保存哪些信息

中国特色审批不能把全部状态塞进流程变量。建议至少拆分：

• wf_task_operation：动作、operationId、任务、操作者、目标人、目标节点和结果；
• wf_approval_record：结构化决定、意见、签名、附件和人员快照；
• wf_approval_policy：节点允许动作、退回策略、加签策略和委托规则；
• wf_participant_snapshot：到达节点时解析出的组织和人员集合；
• wf_cc_record：抄送人、原因、发送时间、已读时间和可见范围；
• wf_delegation_policy：委托人、受托人、有效期、流程范围和排除条件；
• wf_workflow_index：当前节点、业务状态、待办摘要和最后事件版本。

Flowable 保存执行令牌和任务历史，业务表保存审批语义和证据。两边通过 processInstanceId、taskId、businessKey、operationId 和 workflowVersion 关联。

七、安全、性能与治理要求

如何兼顾 BPMN 可移植性和平台扩展

扩展并不意味着放弃标准。关键是把扩展限制在清晰边界内：

• 主干流程尽量使用标准 BPMN 元素；
• 自定义属性放在 extensionElements，并使用稳定的命名空间和版本号；
• 所有 Flowable 专有 API 集中在 Adapter，不散落到业务模块；
• 审批动作使用平台领域模型，不让页面直接调用引擎；
• 部署前校验扩展属性、节点组合和迁移兼容性；
• 为多实例、退回、加签和并行分支建立引擎升级回归测试。

未来迁移到其他 BPMN 引擎时，标准主流程仍可复用，主要改造引擎适配层。若所有中国特色规则都写成 Flowable 监听器和内部表操作，迁移成本就会扩散到每一个业务流程。

哪些反模式应该避免

• 为了看起来“标准”，把抄送、通知和阅读全部画成 User Task；
• 用流程变量保存会签明细、审批意见和完整权限快照；
• 退回时直接操作 ACT_RU_EXECUTION、ACT_RU_TASK 等内部表；
• 在 task listener 中执行长时间远程调用和复杂组织查询；
• 用网关表达式复制整套业务规则，没有版本、测试和审计；
• 把 delegate、transfer、claim 和管理员改派都记录成“换办理人”；
• 只保存最终审批结果，不保存个人意见、轮次和动态参与者变化；
• 前端隐藏按钮就认为权限已经控制，后端没有再次校验。

八、平台落地、测试与选型

低代码平台如何封装中国特色审批

云程低代码开发平台可以让设计器继续使用简洁的 BPMN 主图，同时在节点属性面板配置审批动作、人员规则、表单权限、会签策略和退回策略。发布时生成带版本的扩展配置，运行时由统一 Approval Command Service 解释并执行。

平台价值不在于新增几个自定义图标，而在于把动态参与者、操作语义、审计证据、幂等恢复和权限校验做成跨流程复用的基础设施。这样业务人员看到的是审批主线，开发人员维护的是稳定服务，而不是几十条回边和监听器脚本。