![封面图](https://developer.qcloudimg.com/http-save/yehe-1184138/083c0d6c6699151ee1c83b07da84829d.jpg)

很多团队在接入 JeecgBoot 低代码平台后，面对 "协同工作" 和 "Flowable 流程审批" 两个模块时常常陷入困惑：两个都是处理审批流程的，到底用哪个？能混着用吗？设计上有什么本质区别？

- **协同工作**：临时起意，随手发起，当场选人即走，不用提前画流程，像 "临时拉群办事"。
- **Flowable 流程审批**：事先规划，必须提前画好流程图、配好节点和人员再发布，像 "走正式审批单"。

一句话概括区别：一个是 "先办事后定规则"，一个是 "先定规则再办事"。

本文从定位、发起方式、操作能力、人员配置四个维度系统拆解两者的差异，并给出一套可落地的选型判断框架，帮你在项目初期就做出正确决策，避免后期推翻重来。

#### 一句话先讲清楚 —— 两者根本不是同一功能

很多人把这两个模块当成 "轻量版和重量版的关系"，其实这个理解并不准确。

更贴切的比喻是：协同工作像微信群里临时拉人开会，你想找谁拉谁，随时发起随时结束，灵活但非标；而 Flowable 流程审批像走公司的正式 OA 系统，每一个节点、每一个审批人都提前在流程图里定义好，规范且可追溯。

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

这个定位差异直接决定了后续所有功能设计上的取舍。

#### 发起门槛：随时用 vs 配置后才能用

这是两者最显著的体验差距，也是很多团队 "第一印象" 的来源。

协同工作的发起极为简单：打开页面，填写事项内容，选择参与人，发起。不需要任何预设模板，不需要管理员提前配置，任何用户随时都能用。

Flowable 的发起则依赖完整的前置工作：

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

这意味着 Flowable 是开发 / 管理员驱动的产品，首次使用前需要一次性投入配置成本；而协同工作是用户自驱动的，开箱即用，零配置。

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

实践建议：项目上线初期，业务流程还在磨合期、规则未固化时，先用协同工作跑通，后期流程稳定了再沉淀为 Flowable 标准流程 —— 两者可以形成很好的演进路径。

#### 协同工作的两种内置模式

协同工作内置了两种流转模式，覆盖了大多数轻量化协作场景：

**任意流：并行通知，无先后顺序**

所有参与人同时收到任务，各自独立处理，互不阻塞。适合通知类、信息同步类、并行讨论类场景 —— 比如群发一个技术方案让大家过目，或者通知多个部门同步知悉某项变更。

支持按人员、部门、公司三个维度发起，覆盖跨部门协作场景。

![任意流](https://developer.qcloudimg.com/http-save/yehe-1184138/961ca7790c18b558ac688ab139ce5e49.png)

**步骤流：串行执行，有明确顺序**

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

发起界面：

![步骤流发起界面](https://developer.qcloudimg.com/http-save/yehe-1184138/1fdc1139aeb63efae9dd1437ae14d3ef.png)

办理界面：

![步骤流办理界面](https://developer.qcloudimg.com/http-save/yehe-1184138/f744286ce00cba848b153f6117dc3b98.png)

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

如果说协同工作是 "够用就好"，Flowable 则是 "该有的都有"。它支持完整的 BPMN 2.0 节点体系，能够建模任意复杂的企业审批场景：

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

特别值得关注的是条件网关能力：排他网关用于 "二选一" 的分支（如金额小于 1 万走部门审批，否则走总经理审批），并行网关用于 "多路并行" 然后汇聚，包容网关则介于两者之间，支持更灵活的路由逻辑。这些能力是协同工作的步骤流无法覆盖的。

流程设计器示意：

![流程设计器示意](https://developer.qcloudimg.com/http-save/yehe-1184138/958828605c1e70aaf5648777419c2a8d.png)

#### 操作权限对比：轻便协作 vs 精细管控

两个模块在 "审批过程中能做什么" 上差距非常大，这也是日常使用频率最高的功能区。

协同工作支持的操作以轻量为主：

结束事项、催办、加签、转发、转入流程、取消关注、回复、批复、完成、归档

其中 "转入流程" 是一个亮点设计：当一个协同事项在处理过程中发现需要走正式审批时，可以直接将其转为 Flowable 流程实例，无需重新发起，两个模块之间形成了自然的衔接通道。

![协同工作操作](https://developer.qcloudimg.com/http-save/yehe-1184138/100c808256359465e2c76c7736b0e6da.png)

Flowable 流程审批支持的操作则覆盖了企业审批的全部场景：

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

![Flowable 操作](https://developer.qcloudimg.com/http-save/yehe-1184138/618942b2d5fbe7ee819426cbb62929af.png)

这里有几个操作特别值得关注：

- **委派 vs 转办**：两者容易混淆。转办是 "我不管了，交给你"，自己彻底退出；委派是 "你帮我看一下，看完还得回到我这"，适合处理人需要外部意见但最终还要自己拍板的场景。
- **向前加签 vs 向后加签**：前加签是在自己提交前插入一个额外审核环节；后加签是在自己提交后、下一节点前插入。两者的区别在于加签的位置和时机不同。
- **代理 / 交接**：这是员工离职或长假场景下的兜底机制，管理员可以强制将未完成任务转交，避免流程死锁。

#### 人员配置灵活度

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

Flowable 在人员配置上的核心优势是规则化：不是每次发起时手动选人，而是在流程设计阶段就把 "谁来审" 的逻辑固化下来 —— 可以是指定人员、角色、部门，也可以是动态表达式（比如 "发起人的直属上级"）。这对于标准化流程的一致性执行至关重要。

#### 功能模块全景图

协同工作的七大模块：

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

![协同工作模块](https://developer.qcloudimg.com/http-save/yehe-1184138/f670e7dc7d54e9c132336cbef869f0ae.png)

Flowable 流程审批的六大模块：

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

![Flowable 模块](https://developer.qcloudimg.com/http-save/yehe-1184138/759ccf1c3a977e07295006b7d29ae11a.png)

值得一提的是 Flowable 的流程监控能力 —— 管理员可以实时查看每一个流程实例当前停在哪个节点、各节点耗时如何、整体流转状态是否正常。这对于运营高频业务流程（如合同审批、费用报销）的企业来说是非常有价值的管控视角。

#### 选型决策框架：四个问题帮你做决定

遇到一个新的业务场景，用下面四个问题快速判断：

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

- 有（如：合同必须经过法务→财务→CEO）→ Flowable
- 没有，每次发起者自己决定 → 协同工作

**Q2：是否需要驳回、委派、条件分支等复杂操作？**

- 是 → Flowable
- 否，简单的通知 / 确认 / 轻量审核就够 → 协同工作

**Q3：这个场景有多临时？**

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

**Q4：是否需要和业务表单深度绑定？**

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

汇总参考表：

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

#### 总结

JeecgBoot 低代码平台将 "协同工作" 和 "Flowable 流程审批" 作为两个并行的流程管理工具，并非功能重叠的冗余设计，而是有意识地覆盖了企业内两种截然不同的协作诉求。

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

对于处于成长阶段的企业来说，协同工作是现在，Flowable 是未来 —— 先用协同工作把业务跑通，再把成熟的流程逐步沉淀为 Flowable 标准定义，是一条低成本、可持续的数字化流程建设路径。

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

很多团队在接入 JeecgBoot 低代码平台后，面对 "协同工作" 和 "Flowable 流程审批" 两个模块时常常陷入困惑：两个都是处理审批流程的，到底用哪个？能混着用吗？设计上有什么本质区别？

JeecgBoot 双流程引擎选型指南：协同工作 vs Flowable，别再用错了！

架构设计

开发工具

低代码

JeecgBoot低代码平台中协同工作与Flowable流程审批的本质区别解析：协同工作适合临时灵活协作，无需预设流程；Flowable适用于标准化审批，需提前配置BPMN流程图。前者支持"先办事后定规则"的轻量协作，后者实现"先定规则再办事"的企业级流程管控。两者在发起方式、操作权限、人员配置等方面存在显著差异，可根据业务场景灵活选择或组合使用。

路由

2026年中大促 | AI 领航 智绘未来

weda

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

JeecgBoot低代码平台中协同工作与Flowable流程审批的本质区别解析：协同工作适合临时灵活协作，无需预设流程；Flowable适用于标准化审批，需提前配置BPMN流程图。前者支持"先办事后定规则"的轻量协作，后者实现"先定规则再办事"的企业级流程管控。两者在发起方式、操作权限、人员配置等方面存在显著差异，可根...

JeecgBoot 双流程引擎选型指南：协同工作 vs Flowable，别再用错了！-腾讯云开发者社区-腾讯云

JeecgBoot 双流程引擎选型指南：协同工作 vs Flowable，别再用错了！

JeecgBoot 双流程引擎选型指南：协同工作 vs Flowable，别再用错了！

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐