很多團隊在接入 JeecgBoot 低代碼平臺后，面對 "協(xié)同工作" 和 "Flowable 流程審批" 兩個模塊時常常陷入困惑：兩個都是處理審批流程的，到底用哪個？能混著用嗎？設(shè)計上有什么本質(zhì)區(qū)別？
- 協(xié)同工作：臨時起意，隨手發(fā)起，當場選人即走，不用提前畫流程，像 "臨時拉群辦事"。
- Flowable 流程審批：事先規(guī)劃，必須提前畫好流程圖、配好節(jié)點和人員再發(fā)布，像 "走正式審批單"。
一句話概括區(qū)別：一個是 "先辦事后定規(guī)則"，一個是 "先定規(guī)則再辦事"。
本文從定位、發(fā)起方式、操作能力、人員配置四個維度系統(tǒng)拆解兩者的差異，并給出一套可落地的選型判斷框架，幫你在項目初期就做出正確決策，避免后期推翻重來。
一句話先講清楚 —— 兩者根本不是同一功能
很多人把這兩個模塊當成 "輕量版和重量版的關(guān)系"，其實這個理解并不準確。
更貼切的比喻是：協(xié)同工作像微信群里臨時拉人開會，你想找誰拉誰，隨時發(fā)起隨時結(jié)束，靈活但非標；而 Flowable 流程審批像走公司的正式 OA 系統(tǒng)，每一個節(jié)點、每一個審批人都提前在流程圖里定義好，規(guī)范且可追溯。
| 維度 | 協(xié)同工作 | Flowable 流程審批 |
|---|---|---|
| 定位 | 輕量級 OA 協(xié)同，臨時發(fā)起、靈活流轉(zhuǎn) | 企業(yè)級 BPM 引擎，標準化、規(guī)范化審批 |
| 底層引擎 | JeecgBoot 自研協(xié)同模塊 | Flowable BPMN 2.0 標準引擎 |
| 一句話概括 | 臨時拉群辦事 | 走正式審批單 |
這個定位差異直接決定了后續(xù)所有功能設(shè)計上的取舍。
發(fā)起門檻：隨時用 vs 配置后才能用
這是兩者最顯著的體驗差距，也是很多團隊 "第一印象" 的來源。
協(xié)同工作的發(fā)起極為簡單：打開頁面，填寫事項內(nèi)容，選擇參與人，發(fā)起。不需要任何預(yù)設(shè)模板，不需要管理員提前配置，任何用戶隨時都能用。
Flowable 的發(fā)起則依賴完整的前置工作：
- 在流程設(shè)計器中繪制 BPMN 流程圖
- 配置每個節(jié)點的處理人規(guī)則
- 綁定業(yè)務(wù)表單（Online 表單、設(shè)計器表單或自定義開發(fā)表單）
- 保存并發(fā)布流程定義
- 最終通過業(yè)務(wù)表單觸發(fā)流程實例
這意味著 Flowable 是開發(fā) / 管理員驅(qū)動的產(chǎn)品，首次使用前需要一次性投入配置成本；而協(xié)同工作是用戶自驅(qū)動的，開箱即用，零配置。
| 維度 | 協(xié)同工作 | Flowable 流程審批 |
|---|---|---|
| 是否需要預(yù)設(shè)模板 | 不需要 | 必須提前繪制并發(fā)布 BPMN 流程圖 |
| 誰可以發(fā)起 | 任何用戶隨時新建事項 | 需綁定業(yè)務(wù)表單，按流程定義觸發(fā) |
| 發(fā)起門檻 | 極低 | 較高（依賴開發(fā) / 管理員配置） |
實踐建議：項目上線初期，業(yè)務(wù)流程還在磨合期、規(guī)則未固化時，先用協(xié)同工作跑通，后期流程穩(wěn)定了再沉淀為 Flowable 標準流程 —— 兩者可以形成很好的演進路徑。
協(xié)同工作的兩種內(nèi)置模式
協(xié)同工作內(nèi)置了兩種流轉(zhuǎn)模式，覆蓋了大多數(shù)輕量化協(xié)作場景：
任意流：并行通知，無先后順序
所有參與人同時收到任務(wù)，各自獨立處理，互不阻塞。適合通知類、信息同步類、并行討論類場景 —— 比如群發(fā)一個技術(shù)方案讓大家過目，或者通知多個部門同步知悉某項變更。
支持按人員、部門、公司三個維度發(fā)起，覆蓋跨部門協(xié)作場景。
步驟流：串行執(zhí)行，有明確順序
按順序逐步流轉(zhuǎn)，支持串行、會簽、排他三種步驟模式。適合有先后依賴關(guān)系的輕量審批 —— 比如技術(shù)評審先過組長再過總監(jiān)，或者文檔先由作者確認再由審核員簽字。
發(fā)起界面：
辦理界面：
Flowable 的節(jié)點體系：企業(yè)級審批的完整拼圖
如果說協(xié)同工作是 "夠用就好"，F(xiàn)lowable 則是 "該有的都有"。它支持完整的 BPMN 2.0 節(jié)點體系，能夠建模任意復雜的企業(yè)審批場景：
| 節(jié)點 / 配置 | 說明 |
|---|---|
| 用戶任務(wù) | 可指定處理人、候選人員、候選角色、部門、崗位、職級、自定義表達式等 |
| 網(wǎng)關(guān)（排他 / 并行 / 包容） | 條件分支，按業(yè)務(wù)邏輯自動路由 |
| 簽收 / 認領(lǐng)機制 | 候選人中有人簽收后，其他人的任務(wù)自動消失 |
| 會簽節(jié)點 | 支持一票否決 / 一票通過 / 按百分比投票 |
| 主子流程 | 支持流程嵌套，處理復雜業(yè)務(wù)分支 |
| 表單綁定 | 每個流程可綁定不同的表單類型 |
特別值得關(guān)注的是條件網(wǎng)關(guān)能力：排他網(wǎng)關(guān)用于 "二選一" 的分支（如金額小于 1 萬走部門審批，否則走總經(jīng)理審批），并行網(wǎng)關(guān)用于 "多路并行" 然后匯聚，包容網(wǎng)關(guān)則介于兩者之間，支持更靈活的路由邏輯。這些能力是協(xié)同工作的步驟流無法覆蓋的。
流程設(shè)計器示意：
操作權(quán)限對比：輕便協(xié)作 vs 精細管控
兩個模塊在 "審批過程中能做什么" 上差距非常大，這也是日常使用頻率最高的功能區(qū)。
協(xié)同工作支持的操作以輕量為主：
結(jié)束事項、催辦、加簽、轉(zhuǎn)發(fā)、轉(zhuǎn)入流程、取消關(guān)注、回復、批復、完成、歸檔
其中 "轉(zhuǎn)入流程" 是一個亮點設(shè)計：當一個協(xié)同事項在處理過程中發(fā)現(xiàn)需要走正式審批時，可以直接將其轉(zhuǎn)為 Flowable 流程實例，無需重新發(fā)起，兩個模塊之間形成了自然的銜接通道。
Flowable 流程審批支持的操作則覆蓋了企業(yè)審批的全部場景：
| 操作 | 說明 |
|---|---|
| 簽收 / 認領(lǐng) | 候選人認領(lǐng)任務(wù)，認領(lǐng)后其他候選人不可再操作 |
| 取消簽收 | 取消認領(lǐng)，任務(wù)重回待認領(lǐng)狀態(tài) |
| 審批 | 處理當前節(jié)點，進入下一節(jié)點 |
| 駁回 / 回退 | 打回到之前已處理的節(jié)點，要求重新處理 |
| 轉(zhuǎn)辦 | 將操作權(quán)限轉(zhuǎn)給他人，自己不再參與 |
| 委派 / 委托 | 委托他人代辦，處理完后回到自己手中再提交 |
| 撤銷 | 發(fā)起人撤銷整個流程 |
| 取回 | 上一節(jié)點處理人在下一節(jié)點未處理時退回重操作 |
| 終止 | 處理人強制終止流程 |
| 抄送 | 處理完后抄送他人（創(chuàng)建待閱子任務(wù)，不影響流轉(zhuǎn)） |
| 向前加簽 | 加一個前置審核人，核對后回到自己再提交 |
| 向后加簽 | 加一個后置處理人，核對后直接進入下一節(jié)點 |
| 會簽 | 多人同時處理，支持一票否決 / 通過 / 百分比結(jié)論 |
| 代理 / 交接 | 管理員將離職員工任務(wù)強制轉(zhuǎn)交給代理人 |
| 暫存 / 草稿 | 復雜表單分多次填寫保存 |
| 催辦 | 發(fā)起人以消息通知提醒當前節(jié)點處理人 |
這里有幾個操作特別值得關(guān)注：
- 委派 vs 轉(zhuǎn)辦：兩者容易混淆。轉(zhuǎn)辦是 "我不管了，交給你"，自己徹底退出；委派是 "你幫我看一下，看完還得回到我這"，適合處理人需要外部意見但最終還要自己拍板的場景。
- 向前加簽 vs 向后加簽：前加簽是在自己提交前插入一個額外審核環(huán)節(jié)；后加簽是在自己提交后、下一節(jié)點前插入。兩者的區(qū)別在于加簽的位置和時機不同。
- 代理 / 交接：這是員工離職或長假場景下的兜底機制，管理員可以強制將未完成任務(wù)轉(zhuǎn)交，避免流程死鎖。
人員配置靈活度
| 維度 | 協(xié)同工作 | Flowable 流程審批 |
|---|---|---|
| 指定方式 | 發(fā)起時臨時選擇人員 / 部門 / 公司 | 流程設(shè)計時預(yù)配置，也可運行時動態(tài)指定 |
| 候選人機制 | 無（直接指定） | 有簽收 / 認領(lǐng)機制，候選人搶占任務(wù) |
| 委派代辦 | 不支持 | 支持委派 / 委托，代理 / 交接 |
| 會簽 | 步驟流支持簡單會簽 | 支持完整會簽（一票否決 / 通過 / 百分比） |
Flowable 在人員配置上的核心優(yōu)勢是規(guī)則化：不是每次發(fā)起時手動選人，而是在流程設(shè)計階段就把 "誰來審" 的邏輯固化下來 —— 可以是指定人員、角色、部門，也可以是動態(tài)表達式（比如 "發(fā)起人的直屬上級"）。這對于標準化流程的一致性執(zhí)行至關(guān)重要。
功能模塊全景圖
協(xié)同工作的七大模塊：
| 模塊 | 說明 |
|---|---|
| 事項一覽 | 待辦、經(jīng)辦、發(fā)起、回收箱的件數(shù) / 未讀 / 未批統(tǒng)計總覽 |
| 我發(fā)起的事項 | 展示我發(fā)起的所有事項，可新建事項 |
| 待辦事項 | 展示所有需要我辦理的事項，支持批復、完成、轉(zhuǎn)入流程、關(guān)注、回復 |
| 已辦事項 | 展示我辦理完成的事項，可轉(zhuǎn)發(fā)、轉(zhuǎn)入流程、關(guān)注、回復 |
| 草稿箱 | 保存未發(fā)起的草稿 |
| 查詢事項 | 查詢所有事項，支持刪除（管理員專用） |
| 歸檔 | 已結(jié)束事項可歸檔，歸檔后在檔案管理中查詢 |
Flowable 流程審批的六大模塊：
| 模塊 | 說明 |
|---|---|
| 流程設(shè)計器 | 可視化 BPMN 流程圖繪制，配置節(jié)點、人員、表單 |
| 待辦任務(wù) | 我需要處理的流程節(jié)點任務(wù) |
| 已辦任務(wù) | 我已處理完成的流程節(jié)點記錄 |
| 我發(fā)起的 | 我發(fā)起的所有流程實例 |
| 流程監(jiān)控 | 管理員查看所有流程實例運行狀態(tài) |
| 流程定義管理 | 部署、掛起、激活流程定義 |
值得一提的是 Flowable 的流程監(jiān)控能力 —— 管理員可以實時查看每一個流程實例當前停在哪個節(jié)點、各節(jié)點耗時如何、整體流轉(zhuǎn)狀態(tài)是否正常。這對于運營高頻業(yè)務(wù)流程（如合同審批、費用報銷）的企業(yè)來說是非常有價值的管控視角。
選型決策框架：四個問題幫你做決定
遇到一個新的業(yè)務(wù)場景，用下面四個問題快速判斷：
Q1：這個流程是否有固定的節(jié)點和規(guī)則？
- 有（如：合同必須經(jīng)過法務(wù)→財務(wù)→CEO）→ Flowable
- 沒有，每次發(fā)起者自己決定 → 協(xié)同工作
Q2：是否需要駁回、委派、條件分支等復雜操作？
- 是 → Flowable
- 否，簡單的通知 / 確認 / 輕量審核就夠 → 協(xié)同工作
Q3：這個場景有多臨時？
- 非常臨時，明天可能就不需要了 → 協(xié)同工作
- 會長期固化，需要標準化復用 → Flowable
Q4：是否需要和業(yè)務(wù)表單深度綁定？
- 是，每個節(jié)點都要讀寫表單數(shù)據(jù) → Flowable
- 否，只是溝通協(xié)調(diào) → 協(xié)同工作
匯總參考表：
| 場景 | 推薦模塊 |
|---|---|
| 臨時通知、快速協(xié)作、無固定流程的事項 | 協(xié)同工作（任意流） |
| 有順序但較簡單的內(nèi)部審核 | 協(xié)同工作（步驟流） |
| 標準化業(yè)務(wù)審批（合同、報銷、采購、入職） | Flowable 流程審批 |
| 需要駁回 / 委派 / 完整會簽 / 條件分支等復雜操作 | Flowable 流程審批 |
| 協(xié)作中發(fā)現(xiàn)需要走正式審批 | 協(xié)同工作 → 轉(zhuǎn)入流程 |
總結(jié)
JeecgBoot 低代碼平臺將 "協(xié)同工作" 和 "Flowable 流程審批" 作為兩個并行的流程管理工具，并非功能重疊的冗余設(shè)計，而是有意識地覆蓋了企業(yè)內(nèi)兩種截然不同的協(xié)作訴求。
協(xié)同工作解決的是 "靈活、快速、低門檻" 的日常協(xié)作問題；Flowable 解決的是 "規(guī)范、可控、可追溯" 的業(yè)務(wù)流程治理問題。兩者之間還有 "轉(zhuǎn)入流程" 這一橋梁，讓從輕量協(xié)作自然演進到標準化審批成為可能。
對于處于成長階段的企業(yè)來說，協(xié)同工作是現(xiàn)在，F(xiàn)lowable 是未來 —— 先用協(xié)同工作把業(yè)務(wù)跑通，再把成熟的流程逐步沉淀為 Flowable 標準定義，是一條低成本、可持續(xù)的數(shù)字化流程建設(shè)路徑。
本文為 JeecgBoot AI 專題研究系列文章。
