JeecgBoot低代码双流程引擎怎么选：协同工作 vs Flowable

zhangdaiscott

写在前面：为什么这两个模块总让人纠结

接手 JeecgBoot低代码 平台的团队，几乎都会在某个时刻卡在同一个问题上：系统里既有「协同工作」，又有「Flowable 流程审批」，两个看上去都是处理审批和流转的，到底该用哪个？能不能混着用？如果一开始选错了，后面要不要推翻重做？

这种困惑很正常，因为两者表面上都在解决「一件事要经过几个人」的问题。但只要往下挖一层就会发现，它们的设计哲学根本不在一个频道上。我们不妨先用一句话把这层窗户纸捅破：

• 协同工作：事情来了随手发起，当场拉人、即刻流转，不用提前画流程图，用完即走——像「临时拉个群把事办了」。
• Flowable 流程审批：必须事先把流程图画好、节点配好、人员定好再发布，之后大家照章办事——像「走一张正式的审批单」。

再浓缩一下，就是 「先办事、后定规则」对上「先定规则、再办事」。这一字之差，决定了后面所有功能取舍的方向。

本文不打算逐条罗列功能清单，而是从定位、发起方式、操作能力、人员配置四个维度把差异讲清楚，最后给一套能直接拿去用的判断框架，帮你在项目早期就把账算明白，少走回头路。

别再把它们当成「轻量版」和「重量版」

最常见的误解，是把协同工作理解成「Flowable 的简化版」，觉得两者只是繁简程度不同。这个类比会误导决策。

更贴切的说法是这样：协同工作像微信群里临时开会，想找谁就拉谁，随时发起、随时解散，灵活但不规范；Flowable 则像公司正经的 OA 系统，每一个节点、每一位审批人都在流程图里事先定义好，规范、可追溯，但启动成本更高。

维度	协同工作	Flowable 流程审批
定位	轻量级 OA 协同，临时发起、灵活流转	企业级 BPM 引擎，标准化、规范化审批
底层引擎	JeecgBoot 自研协同模块	Flowable BPMN 2.0 标准引擎
一句话概括	临时拉群办事	走正式审批单

记住这个定位差异——它是后面一切设计取舍的总开关。

发起门槛：打开就能用，还是配完才能用

这是用户对两者的「第一印象」差距，也是最直观的体验分水岭。

协同工作的发起几乎没有门槛：打开页面、写清楚要办什么事、勾选参与人、点发起，结束。它不需要任何预设模板，也不需要管理员提前铺路，任何普通用户随时都能上手。

Flowable 则完全相反，发起之前有一整套必修课要做：

1. 在流程设计器里画出 BPMN 流程图
2. 给每个节点配置处理人规则
3. 绑定业务表单（Online 表单、设计器表单或自定义开发的表单）
4. 保存并发布流程定义
5. 最终由业务表单触发出一个流程实例

换句话说，Flowable 是「开发 / 管理员驱动」的产品，首次启用前需要一笔一次性的配置投入；而协同工作是「用户自驱动」的，开箱即用、零配置。

维度	协同工作	Flowable 流程审批
是否需要预设模板	不需要	必须提前绘制并发布 BPMN 流程图
谁可以发起	任何用户随时新建事项	需绑定业务表单，按流程定义触发
发起门槛	极低	较高（依赖开发 / 管理员配置）

这里给一条实战建议：项目刚上线、业务规则还在反复磨合的阶段，先用协同工作把流程跑顺；等某条流程稳定下来、规则固化了，再把它沉淀成一套 Flowable 标准流程。两个模块之间天然就能形成「从灵活到规范」的演进路径，不必一步到位。

协同工作的两种内置玩法

虽然定位轻量，协同工作内置的两种流转模式已经能覆盖绝大多数日常协作场景。

任意流：并行通知，没有先后

所有参与人同时收到任务，各干各的、互不阻塞。它适合通知类、信息同步类、并行讨论类的场景——比如群发一份技术方案让大家过目，或者把某项变更同步知会多个部门。发起时支持按人员、部门、公司三个维度选择，跨部门协作也能覆盖。

步骤流：串行流转，顺序明确

按顺序一步步往下走，支持串行、会签、排他三种步骤模式。它适合有先后依赖的轻量审批——比如技术评审先过组长再过总监，或者文档先由作者确认、再交审核员签字。

Flowable 的节点体系：企业级审批的完整拼图

如果说协同工作的设计原则是「够用就好」，那 Flowable 的原则就是「该有的一个都不少」。它完整支持 BPMN 2.0 节点体系，几乎能建模任意复杂的企业审批场景：

节点 / 配置	说明
用户任务	可指定处理人、候选人员、候选角色、部门、岗位、职级、自定义表达式等
网关（排他 / 并行 / 包容）	条件分支，按业务逻辑自动路由
签收 / 认领机制	候选人中有人签收后，其他人的任务自动消失
会签节点	支持一票否决 / 一票通过 / 按百分比投票
主子流程	支持流程嵌套，处理复杂业务分支
表单绑定	每个流程可绑定不同的表单类型

特别值得拎出来说的是条件网关：排他网关用于「二选一」分支（例如金额小于 1 万走部门审批，否则直送总经理），并行网关用于「多路同时进行」再汇聚，包容网关则介于两者之间，支持更灵活的路由判断。这类能力是协同工作的步骤流根本覆盖不到的，也是判断「该不该上 Flowable」的关键信号之一。

审批过程能做什么：轻便协作 vs 精细管控

这是日常使用频率最高的功能区，两个模块在「办理时能执行哪些动作」上的差距非常大。

协同工作支持的操作偏轻量：结束事项、催办、加签、转发、转入流程、取消关注、回复、批复、完成、归档。

其中「转入流程」是个亮点设计：当一个协同事项处理到一半，突然发现这事得走正式审批了，可以直接把它转成 Flowable 流程实例，不用推倒重新发起。这条通道让两个模块之间有了自然的衔接，也是「先轻后重」演进策略能落地的技术前提。

Flowable 这边则几乎把企业审批会遇到的所有动作都备齐了：

操作	说明
签收 / 认领	候选人认领任务，认领后其他候选人不可再操作
取消签收	取消认领，任务重回待认领状态
审批	处理当前节点，进入下一节点
驳回 / 回退	打回到之前已处理的节点，要求重新处理
转办	将操作权限转给他人，自己不再参与
委派 / 委托	委托他人代办，处理完后回到自己手中再提交
撤销	发起人撤销整个流程
取回	上一节点处理人在下一节点未处理时退回重操作
终止	处理人强制终止流程
抄送	处理完后抄送他人（创建待阅子任务，不影响流转）
向前加签	加一个前置审核人，核对后回到自己再提交
向后加签	加一个后置处理人，核对后直接进入下一节点
会签	多人同时处理，支持一票否决 / 通过 / 百分比结论
代理 / 交接	管理员将离职员工任务强制转交给代理人
暂存 / 草稿	复杂表单分多次填写保存
催办	发起人以消息通知提醒当前节点处理人

这张表里有几对操作特别容易混淆，单独说明一下：

• 委派 vs 转办：转办是「我彻底不管了，交给你」，自己从此退出；委派是「你帮我看一下，看完还要还给我」，适合处理人需要外部意见、但最终拍板权仍在自己手里的情况。
• 向前加签 vs 向后加签：前加签是在自己提交前插入一个额外审核环节；后加签是在自己提交后、下一节点前插入。区别就在加签的位置和时机。
• 代理 / 交接：这是员工离职或长假场景下的兜底机制。管理员可以强制把未完成的任务转交出去，避免整条流程因为某个人不在而死锁——这一点在实际运维中经常救命。

人员配置：临时点名 vs 规则固化

维度	协同工作	Flowable 流程审批
指定方式	发起时临时选择人员 / 部门 / 公司	流程设计时预配置，也可运行时动态指定
候选人机制	无（直接指定）	有签收 / 认领机制，候选人抢占任务
委派代办	不支持	支持委派 / 委托，代理 / 交接
会签	步骤流支持简单会签	支持完整会签（一票否决 / 通过 / 百分比）

Flowable 在人员配置上的核心价值是规则化：不是每次发起时手动点名，而是在流程设计阶段就把「谁来审」的逻辑固化下来——可以指定具体的人、角色、部门，也可以写成动态表达式（比如「发起人的直属上级」）。对于需要长期一致执行的标准化流程来说，这种确定性比什么都重要，能避免「这次找张三审、下次找李四审」的随意性。

两个模块的功能全景

协同工作：七大模块

模块	说明
事项一览	待办、经办、发起、回收箱的件数 / 未读 / 未批统计总览
我发起的事项	展示我发起的所有事项，可新建事项
待办事项	展示所有需要我办理的事项，支持批复、完成、转入流程、关注、回复
已办事项	展示我办理完成的事项，可转发、转入流程、关注、回复
草稿箱	保存未发起的草稿
查询事项	查询所有事项，支持删除（管理员专用）
归档	已结束事项可归档，归档后在档案管理中查询

Flowable 流程审批：六大模块

模块	说明
流程设计器	可视化 BPMN 流程图绘制，配置节点、人员、表单
待办任务	我需要处理的流程节点任务
已办任务	我已处理完成的流程节点记录
我发起的	我发起的所有流程实例
流程监控	管理员查看所有流程实例运行状态
流程定义管理	部署、挂起、激活流程定义

这里要单独点名 Flowable 的流程监控能力：管理员可以实时看到每一个流程实例当前停在哪个节点、各节点耗时多少、整体流转是否健康。对于跑高频流程（合同审批、费用报销这类）的企业来说，这是一个非常有价值的管控视角——它让「流程卡在哪、卡了多久」从黑盒变成可观测，便于持续优化审批效率。这也是协同工作这种轻量模块刻意没有覆盖的能力。

选型决策框架：四个问题问完就有答案

碰到一个新的业务场景，不用纠结，按下面四个问题挨个过一遍即可：

Q1：这个流程有没有固定的节点和规则？

• 有（比如：合同必须经过法务 → 财务 → CEO）→ Flowable
• 没有，每次由发起者临时决定 → 协同工作

Q2：要不要用到驳回、委派、条件分支这类复杂操作？

• 要 → Flowable
• 不要，简单的通知 / 确认 / 轻量审核就够 → 协同工作

Q3：这个场景有多临时？

• 非常临时，明天可能就不需要了 → 协同工作
• 会长期固化，需要标准化复用 → Flowable

Q4：要不要和业务表单深度绑定？

• 要，每个节点都要读写表单数据 → Flowable
• 不要，只是沟通协调 → 协同工作

汇总成一张速查表：

场景	推荐模块
临时通知、快速协作、无固定流程的事项	协同工作（任意流）
有顺序但较简单的内部审核	协同工作（步骤流）
标准化业务审批（合同、报销、采购、入职）	Flowable 流程审批
需要驳回 / 委派 / 完整会签 / 条件分支等复杂操作	Flowable 流程审批
协作中发现需要走正式审批	协同工作 → 转入流程

实践中还有一个小技巧：如果你拿不准某个场景属于哪一类，默认先用协同工作起步——它的沉没成本几乎为零，跑一段时间后如果发现规则越来越固定、操作越来越复杂，再通过「转入流程」平滑升级到 Flowable，代价远比一开始就重度建模再推翻要小。

---

总结

JeecgBoot低代码 平台把「协同工作」和「Flowable 流程审批」做成两个并行的流程管理工具，不是功能上的重复堆料，而是有意覆盖企业内两类截然不同的协作诉求：

• 协同工作解决的是「灵活、快速、低门槛」的日常协作问题；
• Flowable 解决的是「规范、可控、可追溯」的业务流程治理问题；
• 两者之间还有「转入流程」这座桥，让团队能从轻量协作自然演进到标准化审批。

对处在成长期的企业而言，可以把这两者理解成时间线上的两个阶段——协同工作是现在，Flowable 是未来。先用协同工作把业务跑通，再把那些被验证成熟的流程逐步沉淀为 Flowable 标准定义，是一条低成本、可持续的数字化流程建设路径。选型的本质不是「哪个更强」，而是「当前阶段，哪个更合适」。

---

本文为 JeecgBoot AI 专题研究系列文章。