Zs Admin V1.1.0 把流程能力推进到了可实际承载复杂审批业务的阶段：底层集成 Flowable 7.x，引入仿钉钉的拖拽式流程设计器，并让设计器生成的 JSON 能够兼容标准 BPMN 2.0。对于请假、采购、合同、报销等流程，这意味着业务人员可以负责流程编排，研发人员则把精力集中在条件表达式、审批人解析和业务数据一致性上。
可视化设计器解决的是协作成本
传统 BPMN 开发通常要求工程师直接编辑 XML，或者在独立建模工具中完成流程后再导入系统。流程一旦频繁变化，产品、业务和研发之间就会反复确认节点、连线与条件。
V1.1.0 提供拖拽式流程编排，并让流程图 JSON 自动兼容 BPMN 2.0。这种设计同时服务两类使用者：
- 业务人员通过节点、分支和连线理解审批路径。
- 开发人员仍可围绕 BPMN 2.0 和 Flowable 7.x 接入监听器、变量及外部业务服务。
- 流程定义可以作为结构化数据保存，便于版本管理、发布和回滚。
这里需要明确边界：可视化设计器降低了建模门槛，但不会替代流程治理。节点名称、变量类型、条件优先级和流程版本仍然需要统一规范，否则一张看起来正确的流程图也可能在运行时走错分支。
三类网关分别处理什么问题
V1.1.0 支持并行、排他和包容网关。三者虽然都表现为“分支”，执行语义并不相同。
| 网关 | 适用场景 | 关键行为 |
|---|---|---|
| 排他网关 | 根据金额、类型或地区选择唯一审批路径 | 只选择一个满足条件的分支，通常应设置默认流转 |
| 并行网关 | 法务与财务必须同时审核 | 无条件启动所有分支，并在汇聚点等待 |
| 包容网关 | 根据业务条件启动一个或多个审核分支 | 所有满足条件的分支都会执行 |
以采购审批为例，金额超过 10 万元时进入高级审批，否则进入普通审批，这适合排他网关。合同签署前要求法务和财务同时确认，则适合并行网关。如果涉及数据、外采和品牌等不同事项，需要按条件触发一个或多个专业部门，包容网关更合适。
配置排他网关时，应始终考虑默认流转。金额为空、变量类型错误或条件未覆盖全部范围时，默认流可以避免流程停在网关处。不过，默认流不能掩盖数据质量问题，生产环境仍应记录变量快照和分支选择结果。
审批人解析比画流程更容易出错
该版本内置 12 种审批人解析策略，覆盖岗位、角色、部门领导、多级审批和自选审批人等业务模式。它们解决的核心问题是：流程定义描述“由谁审批”，运行时再根据发起人和组织数据找到具体账号。
落地时建议把审批人解析视为独立的领域能力，并检查以下情况：
- 角色下没有有效用户时，是阻止发起、转交管理员，还是走默认审批人。
- 部门没有负责人时，是否继续向上级部门查找。
- 多级审批遇到同一人员重复出现时，是否自动去重。
- 自选审批人是否限制在指定部门、角色或候选集合内。
- 员工调岗、离职后，运行中的任务如何迁移。
这些规则应在流程发布前完成校验。否则，流程已经创建实例后才发现候选人为空，修复成本会明显增加。
可以这样实践：定义一个带条件分支的采购流程
下面是一个最小 BPMN 2.0 示例，用排他网关按采购金额选择审批路径。它不是对 Zs Admin 内部接口的声明，而是可用于理解和验证 Flowable 兼容性的实践模板。将内容保存为 purchase-approval.bpmn20.xml，再根据项目实际的流程导入或部署入口使用。
<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:flowable="http://flowable.org/bpmn"
targetNamespace="https://example.com/processes">
<process id="purchaseApproval" name="采购审批" isExecutable="true">
<startEvent id="start" name="提交申请" />
<userTask id="managerApproval"
name="直属主管审批"
flowable:candidateGroups="department-manager" />
<exclusiveGateway id="amountGateway" name="判断采购金额"
default="toNormalApproval" />
<userTask id="directorApproval"
name="高级审批"
flowable:candidateGroups="finance-director" />
<userTask id="normalApproval"
name="普通审批"
flowable:candidateGroups="finance-reviewer" />
<endEvent id="end" name="审批完成" />
<sequenceFlow id="toManager" sourceRef="start" targetRef="managerApproval" />
<sequenceFlow id="toGateway" sourceRef="managerApproval" targetRef="amountGateway" />
<sequenceFlow id="toDirectorApproval"
sourceRef="amountGateway"
targetRef="directorApproval">
<conditionExpression xsi:type="tFormalExpression"><![CDATA[${amount >= 100000}]]></conditionExpression>
</sequenceFlow>
<sequenceFlow id="toNormalApproval"
sourceRef="amountGateway"
targetRef="normalApproval" />
<sequenceFlow id="directorToEnd" sourceRef="directorApproval" targetRef="end" />
<sequenceFlow id="normalToEnd" sourceRef="normalApproval" targetRef="end" />
</process>
</definitions>
如果部署环境开放了 Flowable 标准 REST 服务，可以这样提交文件；运行前需要把地址、认证信息和租户参数调整为实际配置。如果 Zs Admin 使用自有发布接口，则应通过系统提供的流程发布入口上传，不要直接绕过其权限与版本控制。
curl -u admin:change-me \
-X POST "http://localhost:8080/process-api/repository/deployments" \
-F "file=@purchase-approval.bpmn20.xml" \
-F "deploymentName=purchase-approval-v1"
部署前至少应验证三组变量：amount=99999、amount=100000，以及 amount 缺失或类型错误。前两组用于检查条件边界，后一组用于确认系统的参数校验和异常处理是否符合预期。
上线前不要只检查流程图
引入 V1.1.0 时，可以按以下清单推进：
- 统一流程变量命名、类型和必填规则。
- 为排他网关设置可解释的条件，并评估默认流转。
- 为 12 种审批人策略分别定义空结果、重复人员和越权选择的处理方式。
- 流程发布后固定版本，运行中的实例不要无条件切换到新定义。
- 记录节点进入、候选人解析、任务领取和分支选择等审计信息。
- 用真实组织结构和边界金额执行回归测试，而不只是预览流程图。
Flowable 7.x、BPMN 2.0 兼容和可视化设计器提供了完整的流程技术底座，但系统能否稳定运行，仍取决于组织数据质量、条件规则、版本管理和异常兜底。先选一条规则清晰、影响范围可控的审批流程试点，再逐步迁移复杂流程，会比一次性替换全部审批链路更稳妥。