SpringBootFlowable 多人审批方式设计依次签、会签、或签、随机一人怎么选怎么实现演示地址http://ruoyioffice.com | 源码1·GitHubruoyi-office | 源码2·GitCoderuoyi-office | 源码3·Giteeruoyi-office | 微信17156169080备注「RuoYi Office」用车申请「部门负责人」节点配了三个角色成员——接下来系统该怎么办三个人必须按顺序批还是谁先点谁算还是要凑齐三分之二候选人策略解决「谁来审」多人审批方式解决「多人时怎样算过」。二者常被混为一谈本文按 RuoYi Office 简单流程设计器与 Flowable 多实例配置拆开。▲ 四种方式对比依次 / 会签比例 / 或签 / 随机底层靠 approveMethod completionCondition引言一个节点、多个人四种完全不同的业务语义业务说法应对方式典型场景先 A 再 B不能插队依次审批科长 → 处长同节点多人顺序大家一起表态过半/全过会签按比例评审会、集体决策谁在岗谁批一人即可或签值班岗、同质审批人别让所有人待办爆炸随机一人客服/行政同质岗位分流选错的后果很直观本该或签却配成会签 → 一人休假整单卡住本该会签却配成或签 → 集体决策变成「手快者得」。一、设计器里长什么样在流程模型 → 简单流程中点开审批节点右侧「审批人设置」下方有多人审批方式按顺序依次审批会签按通过比例或签一人通过或拒绝随机挑选一人审批上方仍要先选候选人策略指定角色/部门负责人/发起人自选等——先确定人从哪来再确定多人怎么过。▲ 用车申请「部门负责人」节点指定角色 依次审批可切换会签/或签/随机▲ 从流程模型进入设计器配置发布后运行时按多实例行为执行二、枚举与完成条件源码publicenumBpmUserTaskApproveMethodEnum{RANDOM(1,随机挑选一人审批,null),RATIO(2,多人会签(按通过比例),${ nrOfCompletedInstances/nrOfInstances %s}),ANY(3,多人或签(一人通过或拒绝),${ nrOfCompletedInstances 0 }),SEQUENTIAL(4,依次审批,${ nrOfCompletedInstances nrOfInstances });}SimpleModelUtils.processMultiInstanceLoopCharacteristics的要点方式sequentialcompletionCondition备注随机不建多实例—只抽一人普通单任务或签 ANYfalse并行完成数 0一人过/拒即可推动依次 SEQUENTIALtrue完成数 ≥ 实例数loopCardinality1 配合顺序会签 RATIOfalse并行完成数/总数 ≥ 比例需配置 approveRatioif(approveMethodEnumANY){multiInstanceCharacteristics.setCompletionCondition(ANY条件);multiInstanceCharacteristics.setSequential(false);}elseif(approveMethodEnumSEQUENTIAL){multiInstanceCharacteristics.setCompletionCondition(SEQUENTIAL条件);multiInstanceCharacteristics.setSequential(true);multiInstanceCharacteristics.setLoopCardinality(1);}elseif(approveMethodEnumRATIO){// 比例如 100 → 1.0060 → 0.60setCompletionCondition(format(RATIO条件,approveRatio/100D));setSequential(false);}扩展属性approveMethod写入 BPMN便于运行时与前端时间轴解释「这个节点当初怎么配的」。三、运行时行为或签要通过时别人的待办哪去了Flowable 在或签一人通过后往往会删除其余未完成的并行任务。若本地任务状态表不补写时间轴会残留「审批中」脏数据。RuoYi Office 在processTaskCanceled中把这类任务标为已取消注释写得很直白或签场景 审批通过其它或签任务被引擎删除时需要更新状态为已取消。会签未达比例时其他人继续待办达比例后同样可能取消剩余实例——产品文案上建议显示「因会签已通过而取消」避免用户以为系统丢单。▲ 待办是运行时入口或签时多人可能同时看到同一节点一人通过后其他人待办应消失或显示取消四、和「加签 / 转办 / 候选人策略」的边界能力解决什么不是什么候选人策略人从哪来角色/部门/自选…不决定多人如何通过多人审批方式多人时如何算节点完成不临时插人加签运行中临时前后插人不是模型上的会签配置转办 / 委派换人 / 请人代办不改变会签或签语义常见误区把「会签」做成加签一圈——能跑但审计语义、完成条件、待办数量都不一样。模型能静态表达的优先用approveMethod。五、选型清单可直接贴进评审问题建议必须按职级顺序不能并行依次审批需要集体同意允许少数缺席会签 通过比例如 60%/100%岗位互为备份一人批即可或签候选人很多不想待办刷屏随机一人注意公平与审计驳回后要整单结束还是退回另配「驳回处理」与多人方式正交用车申请「车辆管理岗」常配或签「部门会签」类节点用会签「先部门负责人再分管领导」若放在同一节点多人则用依次更常见是拆成两个节点更清晰。六、快速体验在线演示http://ruoyioffice.com/web/账号admin/admin123流程中心 → 流程模型打开用车申请或任意简单流程。点开审批节点切换依次 / 会签 / 或签 / 随机观察是否出现通过比例。发布后用多个账号发起单据看待办是否并行、一人通过后他人待办是否取消。对比时间轴文案是否与配置一致。源码仓库GitHub | GitCode | Gitee常见问题FAQ会签比例填 100 和依次审批有何不同会签默认并行所有人同时收到待办需全部完成按比例才过依次是串行前一人不批后一人看不到。体验与耗时差很多。或签一人拒绝会怎样取决于完成条件与驳回配置。ANY 的条件是「完成数 0」通过或拒绝都可能结束多实例——务必在测试环境用双人验证拒绝路径。随机一人还会生成多个任务吗不会按多实例展开实现上不设置 MultiInstance等价于从候选人中选一个 assignee。为什么或签通过后时间轴还有「审批中」多半是引擎删任务后本地状态未补写。应走processTaskCanceled一类补偿逻辑。和候选人「发起人自选多人」一起用吗可以自选决定名单approveMethod 决定这批人如何通过。两套配置都要测。结语多人审批方式的本质是把业务语言翻译成 Flowable 多实例参数顺序还是并行、一个人说了算还是按比例、要不要随机减负。配好approveMethod再补上或签取消态待办与时间轴才经得起审计。下一篇若继续深挖可以专讲会签比例与驳回策略的交叉用例。你们项目里会签和或签是模型配置还是全靠加签临时拉人有没有踩过「或签通过了别人还挂着待办」欢迎评论区交流。想要体验 RuoYi Office 的强大功能在线演示http://ruoyioffice.com/web/账号 admin / admin123源码仓库GitHub | GitCode | Gitee技术咨询添加微信17156169080备注「RuoYi Office」⭐如果觉得不错请给个 Star 支持一下