Flowable多人审批怎么设计？角色、顺序和业务状态一次说清

Flowable多人审批怎么设计？角色、顺序和业务状态一次说清

流程图上只有一个“财务复核”节点，为什么财务点了通过，申请还没有结束？

在RuoYi Office的一次维修单教学验证中，原因很具体：财务角色里有三位成员，节点采用依次审批。第一人完成以后，后面还有两个人要办理。页面没有卡死，业务状态也没有丢失，是对节点规则的理解出了偏差。

这个案例说明，配置审批至少要回答三个问题：哪些人参与、这些人怎样共同完成、节点结果怎样影响整张单据。只选一个角色，后两个问题并不会自动得到业务想要的答案。

图示用于比较多人组织方式，具体通过、拒绝及回退行为还要看节点配置和服务实现。

一次真实审批，先看任务到底停在哪里

2026年10月的教学维修单先经过部门负责人，再进入财务。财务角色实际包含财务专员、核算会计和出纳，模型中的approveMethod为4，也就是本项目的依次审批。

第一次财务办理后，申请仍处于流程中。核对运行任务发现下一位财务成员还有任务，因此没有手工把主表改成“已通过”，也没有临时修改审批配置，而是继续办理原实例。

[实测·历史教程] 设计器只画出一个财务复核节点，角色成员数量与多人方式决定其实际办理过程。

[实测·历史教程] 当前待办展示原单内容，完成这一项不代表整个实例结束。

整个教学主线只正式提交一次。最终业务主表状态为2，流程结束，原单的两条明细、1280元预算和一个附件保留。这些是该案例的实际结果；本文没有另外运行一套或签和会签对照实验。

“选谁”与“怎么完成”，是两个配置维度

角色是候选人来源。审批方式则决定这些候选人怎样构成任务、什么时候结束当前节点。

假设财务角色里有三个人，同样的候选范围，可以承载不同业务意思：由其中一人代表部门处理，要求若干人共同确认，或者按顺序依次办理。界面里都可能叫“财务审核”，但责任完全不同。

本项目枚举BpmUserTaskApproveMethodEnum定义了四种方式：

这里说的是RuoYi Office当前实现的命名与配置，不能直接当作所有Flowable项目都采用同一个枚举值。迁移模型时，应核对目标系统的模型转换和任务处理逻辑。

例如本项目的或签完成表达式包含nrOfCompletedInstances > 0，依次审批包含nrOfCompletedInstances >= nrOfInstances。这些表达式描述多实例完成条件，但“任务完成”与“审批通过”不能不加区分地混写。

拒绝处理还有专门的服务逻辑和节点配置。只看一个计数表达式，就断言“完成一个任务必定整单通过”，会漏掉拒绝、回退以及后续节点。

设计器里的选项，怎样变成运行规则

简单模型转换器SimpleModelUtils会将审批方式转换为Flowable多实例属性。下面节选或签与依次两个分支：

if (approveMethodEnum == BpmUserTaskApproveMethodEnum.ANY) {
multiInstanceCharacteristics.setCompletionCondition(approveMethodEnum.getCompletionCondition());
multiInstanceCharacteristics.setSequential(false);
} else if (approveMethodEnum == BpmUserTaskApproveMethodEnum.SEQUENTIAL) {
multiInstanceCharacteristics.setCompletionCondition(approveMethodEnum.getCompletionCondition());
multiInstanceCharacteristics.setSequential(true);
multiInstanceCharacteristics.setLoopCardinality("1");
}

会签分支则读取配置比例，生成完成条件，并采用非顺序的多实例设置。

读源码时，一个容易误判的地方是上面的setLoopCardinality("1")。不能只看到这个常量，就认为依次审批永远只有一人。本项目还使用自定义的BpmSequentialMultiInstanceBehavior，运行时解析候选人集合并返回其大小。

assigneeUserIds = new LinkedHashSet<>(
taskCandidateInvoker.calculateUsersByTask(execution));

return assigneeUserIds.size();

这两个节选对应候选人计算与实例数返回，中间还有空候选人处理和执行变量保存。模型转换与运行行为合起来，才能解释为什么教学案例中的财务节点确实产生了三人的依次办理过程。

LinkedHashSet可以保留传入顺序，但不能据此推导系统会自动按职级排序。若需求是“会计先核算，经理再批准，出纳最后处理”，应验证候选顺序的来源；更清楚的方案往往是把不同责任拆成显式节点，而不是让角色成员的遍历顺序承担业务约定。

这条建议尤其适用于不同岗位需要看不同字段、填写不同结果的流程。相同审批责任可以放在一组，业务职责已经不同，就值得让流程图把差异表达出来。

角色选对了，还要看组织范围

“财务”可能是整个集团的角色，也可能是某一家公司的角色。配置时只看到一个角色名称，不意味着执行时的人选范围符合当前申请的组织归属。

本轮读取的BpmTaskCandidateRoleStrategy实现中，有按组织范围解析部门，再查询对应角色成员的路径。对于明确的部门范围，它调用：

permissionApi.getUserRoleIdListByRoleIdsAndDeptIds(
roleIds, scopeDeptIds).getCheckedData()

这样查询的是范围内的角色任职关系。它与“先把所有拥有该角色的人取出来，再看这些人是否在某部门任职”不完全相同：同一个人可能在总部承担管理员职责，在子公司只有其他职责，不能把两种任职拼成子公司的管理员身份。

这部分是当前源码分析，教学案例并没有验证全部跨组织组合。正式配置时，可以选一个本组织成员、一个跨组织兼职成员和一个不在范围内的成员，分别核对预览与实际任务。

空候选人也应单独测试。自定义串行行为对空集合保留一个空元素，以便继续创建任务并进入后续处理，而不是在这里因为集合为空就自动通过。最终采用管理员处理、自动操作还是其他策略，需要继续看节点配置，不能仅凭这一层代码承诺业务会自动有人接手。

一个人完成、节点完成、实例完成，是三种结果

排查“审批后状态没变”，可以沿三个层次走。

先看个人任务：办理动作有没有成功，任务是否留下处理记录。再看当前节点：是否还存在其他待办，是否等待比例或顺序条件。最后看实例：是否还有后续节点，是否真的结束，再核对业务状态回写。

[实测·历史教程] 办理历史用于对应原实例。应结合实际待办与业务回查判断结果，而不只看最后一次按钮提示。

维修教学单据通过业务主表ID与流程关联，完成后回写processStatus。它没有因为某位财务完成任务就提前宣告维修业务已经结束，也没有自动产生付款或库存动作。

[实测·历史教程] 申请人回到同一单号核对业务状态，与前面的流程历史交叉检查。

如果实例仍在运行，先去查剩余任务；如果实例已经结束、业务单却没有更新，再查关联ID、结束状态及回写处理。这个顺序能减少把正常等待误判成回调故障的情况。

直接手工改业务表看似能让页面显示“通过”，却会让流程与业务失去一致性。下一个人再回查待办、历史和附件时，可能得到互相冲突的结果。修复应该落在实际错误的配置或实现上，并沿原对象复查。

上线前，给多人审批准备一组小而明确的测试

不需要一开始穷举所有组合，但至少把责任边界转成可执行问题。

模型调整也应有版本意识。下一次发起应该使用什么定义，正在运行的实例是否迁移，历史记录怎样解释，都应明确安排。不要为了让眼前案例更快结束，临时改配置再把旧实例的结果当作新模型验证。

RuoyiOffice建议：先确定责任，再选择会签或或签

如果一组人的职责可以互相替代，讨论由一人代表处理是否合理；如果每个人必须分别确认，讨论会签或依次；如果每个人承担不同业务工作，就考虑拆成清楚的节点。

团队经常变动时，应重点核对角色范围、组织任职和空候选人；对有明确先后职责的流程，不适合用一个宽泛角色来代替完整设计。

多人审批的难点不是把三个人放进一个节点，而是让每个人知道自己承担什么，让系统能解释此刻为什么还在等待。把候选范围、完成规则和业务状态分别说清楚，流程图才会成为能执行的业务约定。