一句话回答会签、或签解决“多人怎样形成一个审批结论”加签解决“运行中怎样增加参与人”转办、委托解决“当前任务责任怎样转移”传阅、抄送解决“信息怎样触达但不参与审批决策”。最容易混淆的地方是只看“这个人能不能收到一条待办”。判断七种操作真正的区别应同时看五件事是否形成审批意见、产生几个任务、谁承担最终责任、是否阻塞主流程、是否要求接收人确认。一、先把七个概念分成三类七个概念可以先分组多人决策会签、或签运行时变更加签、转办、委托信息触达传阅、抄送。图 1先看业务目的再看具体按钮。会签与或签形成决策转办与委托改变责任传阅与抄送只负责信息触达。加签比较特殊它不是一种固定审批模式而是运行中的人员变更动作。加签后新增的人可以参加会签也可以成为前置、后置或并行审批人。二、判断一种操作先回答五个问题判断问题为什么重要是否需要给出同意、拒绝等结论区分审批与阅读通知会生成一条还是多条任务决定候选任务或多实例实现谁对任务结果承担责任区分转办与委托接收人未处理时主流程是否等待区分审批、传阅与抄送是否要求阅读确认区分传阅与普通抄送如果平台只保存 operationTypeTRANSFER却没有定义上面五项同一个“转办”按钮在不同业务系统中可能产生完全不同的结果。三、会签多人分别办理再汇总一个结论会签的核心是“多人都有自己的办理责任”。系统通常为每位会签人创建独立任务再按照汇总规则决定节点是否完成。常见会签模式包括并行会签多人同时收到任务串行会签按照名单顺序逐人办理全员通过所有人同意才通过比例通过例如同意人数达到 60%票数通过例如至少 3 人同意一票否决任意一人拒绝即结束负责人终审其他人给意见负责人形成最终结论。Flowable 可以用 Multi-instance User Task 表达串行或并行会签并用 completionCondition 提前结束剩余实例。但 nrOfCompletedInstances 只表示完成数量不天然等于“同意数量”。平台仍需保存每个人的结构化结果并计算 approvedCount、rejectedCount。会签要提前定义分母口径。审批人请假、重复、被加签或被移除后比例是否重算提前满足通过条件时其他任务是取消、跳过还是未参与这些状态会影响审计和统计。四、或签多人有资格但通常只需要一个人办理“或签”在不同产品中有两种常见实现必须明确。1. 候选人共享一条任务这是更常见、也更接近 Flowable Candidate Users/Groups 的实现。系统只创建一条任务多名候选人都能看到其中一人 claim 后成为 assignee其他人的候选列表中不再显示最终只有一份审批结果。这种模式适合“部门内任一值班经理审批”“客服组任一人接单”。它的重点是抢占和并发控制而不是多人投票。2. 多人各有任务任一人完成即结束有些产品把这种模式也叫或签系统同时创建多条任务任何一人同意后取消其他任务。它更接近带提前完成条件的并行多实例。两种实现的历史记录、任务数量和并发行为不同。平台最好分别命名为“候选抢签”和“多人或签”不要只用一个含糊的 OR_SIGN。图 2会签为多人创建独立任务并汇总候选或签只有一条共享任务加签是在运行时向当前审批结构增加参与人。五、加签运行过程中临时增加审批人加签的核心不是“换人”而是“增加人”。原审批人通常仍在流程中只是新参与人的位置和完成规则发生变化。常见类型包括加签类型执行顺序原审批人怎样变化前加签新增人员先办理原任务暂停完成后回到原审批人后加签原审批人先办理原任务完成后再创建新增任务并行加签新人与原审批人同时办理共同进入汇总规则串行加签多名新增人员依次办理按指定顺序推进加签并转交新人办理后流程直接继续原审批人不再二次办理加签必须明确是否改变会签分母、是否允许继续加签、加签人能否再加签、重复人员怎样处理、原审批人能否撤销加签。技术上加签可能涉及动态增加多实例人员、创建受控子任务、修改执行结构或进入预先设计的加签子流程。不要简单插入一条孤立任务它必须能阻塞或汇合到原任务并进入统一历史和权限体系。六、转办任务和办理责任一起交给另一个人转办通常表示当前办理人将任务永久交给目标人原办理人退出当前任务目标人成为新的责任人。转办后通常具有以下语义当前任务仍是同一业务任务不新增审批环节assignee 从原办理人变为目标人目标人可以直接完成、拒绝或继续执行允许的操作原办理人失去办理权限但保留转办记录流程完成后主要办理责任记在目标人名下。引擎的 setAssignee 或重新分配 API 可以完成受理人变化但平台仍要校验转办权限、目标人员范围、岗位合规、数据可见范围和转办原因。转办不是加签。加签保留原办理链路并增加参与人转办是把当前责任交出去。七、委托别人代办但原责任人通常仍是所有者委托表示原办理人临时请另一个人代为处理。推荐使用 owner 与 assignee 分离owner 保存原责任人assignee 指向受托人delegationState 记录委托是否处理中受托人处理后 resolve任务返回 owner 确认或按平台策略直接继续。Flowable TaskService 的 delegateTask 会把当前 assignee 保存为 owner并把新用户设为 assignee同时进入 PENDING 委托状态resolveTask 表示受托人已处理可以返回 owner。处于 PENDING 委托状态的任务不能直接按普通方式 complete。不过一些 OA 产品把“委托”定义为全权代理受托人处理后流程直接继续不再返回原办理人。两种模式都可以实现但必须在产品上分别叫“协助委托”和“全权委托”并在审计中同时保存 owner、delegatee 和最终完成人。转办与委托的关键区别是转办改变最终责任人委托通常只改变当前执行人。八、传阅要求阅读或确认但不形成审批结论传阅用于让相关人员了解内容常见于公文、制度、会议纪要和风险通知。它通常不要求同意或拒绝但可能要求“已读”“确认收到”或填写阅读意见。传阅可以设计为非阻塞传阅主流程继续传阅任务独立完成阻塞传阅必须全部或部分确认后主流程才能继续限时传阅到期自动结束并记录未读人员逐级传阅阅读人可继续向下传阅。如果需要已读确认应创建独立的 Read Task 或平台阅读记录而不是只发一条消息。传阅记录至少保存发送人、接收人、发送时间、首次查看时间、确认时间和阅读意见。传阅不是会签因为阅读人不参与审批结果也不是普通抄送因为平台通常需要跟踪阅读状态。九、抄送告知相关人默认不等待、不确认抄送的核心是信息同步。抄送人能在“抄送给我”中查看流程、表单或审批结果但不承担办理责任。典型特点是不生成可办理审批任务不要求同意、拒绝或填写意见默认不阻塞流程可以发送站内信、邮件、钉钉或企业微信消息是否允许评论、下载附件、继续转发由权限策略决定。抄送可以发生在流程启动、某节点完成、流程结束或异常时。平台应区分“抄送事件”和“抄送接收人”避免重复通知并明确抄送带来的是查看权限还是仅消息提醒。抄送不是传阅。需要可审计的阅读确认时应升级为传阅仅仅让对方知道则使用抄送。十、一张表看清七种操作类型主要目的任务数量是否形成审批结论原责任人默认是否阻塞会签多人共同决策多条是汇总每人分别负责是或签多人中一人办理一条或多条是一人形成命中者负责是加签临时增加参与人增加任务通常是通常保留是转办永久转移任务通常仍一条是原人退出是委托临时代办通常仍一条是或先返回原人通常仍为 owner是传阅阅读与确认阅读任务或记录否不涉及默认否抄送信息告知通知或可见记录否不涉及否“默认”非常重要。平台可以把传阅设为阻塞把全权委托设为直接完成也可以把或签实现为多个任务。但只要改变默认语义就必须在设计器和运行日志中清楚表达。十一、转办、委托、传阅和抄送的责任流图 3转办把责任交出去委托保留原 owner传阅要求阅读抄送只告知。权限上也有明显差异转办目标人获得完整办理权限受托人只获得委托范围内权限是否能再次转办或加签应受限传阅人获得阅读与确认权限不应出现同意、拒绝按钮抄送人通常只有查看权限敏感字段仍应继续脱敏。十二、在 Flowable 中怎样映射业务语义Flowable 可复用原语仍需平台补齐会签Multi-instance、completionCondition票数、意见、分母和提前结束审计候选或签candidateUsers/groups、claim抢签权限、并发提示和超时释放多任务或签并行多实例、提前完成其他任务取消原因和副作用处理加签动态多实例、子任务或状态变更加签类型、位置、权限和汇总规则转办setAssignee 或任务分配 API目标校验、责任审计和数据权限委托delegateTask、resolveTask、owner返回或直接继续的产品策略传阅独立任务、Identity Link 或平台记录已读回执、阅读意见和非阻塞执行抄送Identity Link、事件与通知服务可见权限、渠道、去重和回执Camunda 8 User Task 也支持 assignee、candidateUsers、candidateGroups、assign、reassign、unassign 和任务生命周期监听器。这些是实现任务分配的基础但“加签”“传阅”“抄送”等中国式语义仍应由平台定义。引擎 API 只负责状态变化业务操作服务还要负责授权、表单权限、通知、审计、重复点击和并发控制。十三、平台应该保存怎样的操作记录每次操作至少应记录operationId、operationType 和发生时间processInstanceId、taskId、activityIdoperator、owner、原 assignee 和新 assigneetargetUsers、targetGroups 和人员解析快照操作前后的任务、执行和多实例摘要reason、comment、附件和电子签名对会签分母、剩余任务和后续路径的影响通知发送、外部副作用和补偿结果调用来源、客户端、IP、租户和幂等键。前端按钮名称可以调整审计事件类型必须稳定。例如 TRANSFER、DELEGATE、RESOLVE_DELEGATION、ADD_BEFORE、ADD_AFTER、CIRCULATE、CC_NOTIFY 应有独立编码不能都记成 UPDATE_TASK。十四、设计器与任务中心应该怎样呈现设计阶段应配置会签类型、通过规则、否决规则和提前结束策略或签采用候选一任务还是多任务抢答是否允许加签、转办、委托以及目标人员范围委托后返回 owner 还是直接继续传阅是否阻塞、是否要求确认抄送时机、可见字段和通知渠道。运行阶段应展示当前操作会影响谁、取消哪些任务、是否改变会签分母转办后原办理人是否退出委托任务将返回谁传阅是否等待确认抄送人能查看哪些数据。高风险操作应先生成影响预览再要求填写原因并二次确认。失败时必须整体回滚不能出现引擎状态已经改变、平台审计却没有写入的半成功状态。十五、低代码工作流平台怎样统一这些能力云程低代码开发平台可以在 Flowable 之上建立统一 Approval Operation Service将七类操作定义为稳定的领域命令用 Engine Adapter 把领域命令映射为 Flowable API用 Approval Policy 保存节点允许的操作及目标范围用 Task Center 统一展示办理、传阅和抄送用表单权限服务决定不同角色可见和可编辑字段用审计服务保存责任变化、任务快照和操作原因用通知服务处理站内信、uniAPP、钉钉和企业微信。这样业务系统面对的是稳定的中国式工作流语义而不是直接操作 TaskService 或引擎数据库表。