员工离职后，如何批量移交待办任务处理权限和已办任务阅读权限？以 Flowable 举例说明

在OA系统/工作流系统里，员工离职后，如何批量移交待办任务处理权限和已办任务阅读权限？员工离职交接必须分成两条链路。仍在运行的待办任务，需要把“谁可以继续办理”迁移给接收人；已经完成的任务，则应保留原办理人和原审批轨迹，只给接收人增加受控的阅读授权。前者会改变 Flowable 运行时任务，后者通常应由 OA 或业务系统的权限表承载。

对于直接分配给离职员工的待办，Flowable 8 可以通过 TaskService.setAssignee 逐项变更办理人；候选人、候选组、委托任务和多实例任务必须按各自语义处理。对于已办任务，不要更新 ACT_HI_TASKINST.ASSIGNEE_，也不要把接收人伪装成历史办理人，而应建立“离职交接阅读授权”，保存授权范围、期限、来源批次和审计记录。

一套可靠的批量交接方案还需要预检查、分类、分批事务、幂等、并发校验、失败重试、结果对账和可回滚机制。它不是一条 SQL 更新语句，更不能在删除组织关系后才开始统计任务。

一、核心结论与问题边界

一句话回答：待办迁办理权，已办授阅读权，历史事实不改写

离职交接包含两种性质完全不同的权限：

权限	作用对象	是否改变流程状态	推荐实现
待办办理权	当前仍存在的活动任务	是	Flowable 任务分配与身份链接 API
已办阅读权	已完成任务、流程和业务单据	否	业务权限授权记录 + Flowable 历史查询

办理权允许接收人填写表单、提交审批、转办或退回，属于运行时操作权限。阅读权只允许查看原审批意见、附件和轨迹，不允许以离职员工身份补签、修改历史意见或重新完成任务。

如果系统只把离职员工账号禁用，没有迁移待办，流程会停在无人可办的状态；如果把全部历史记录的办理人改成接收人，又会破坏审计事实。正确做法是让“当前责任”发生转移，让“过去发生过什么”保持不变。

为什么不能把离职交接理解成批量 setAssignee

一个员工在流程系统中的关系不只有 assignee。离职盘点至少要区分：

• 直接办理人：任务已经分配给该员工。
• 任务 owner：员工是任务责任人，任务可能已委托给其他人。
• 候选用户：任务尚未认领，该员工是可认领人之一。
• 候选组成员：员工因为部门、角色或岗位而拥有候选资格。
• 委托办理人：任务处于委托待处理状态，完成后可能返回 owner。
• 流程发起人、抄送人和传阅人：可能只有阅读或跟踪权限。
• 已办办理人：员工已经完成过任务，是不可改写的审计事实。

其中只有第一类通常直接使用 setAssignee。候选组权限可能只需要调整组织成员关系；委托任务要判断离职员工是 owner 还是当前 assignee；已办任务只增加阅读授权。把所有情况统一改 assignee，会产生重复候选、委托无法回收和历史查询错乱。

二、关键概念与能力差异

Flowable 中哪些数据与离职交接有关

Flowable 的任务数据可以分为运行时和历史两层：

• ACT_RU_TASK 保存当前活动任务，包含 assignee、owner、delegation state、流程实例和任务定义等信息。
• ACT_RU_IDENTITYLINK 保存当前任务的候选用户、候选组和其他身份关系。
• ACT_HI_TASKINST 保存进行中及已结束任务的历史快照，包括原办理人、开始时间、结束时间和删除原因。
• ACT_HI_IDENTITYLINK 保存历史身份关系。

官方历史文档明确说明，历史组件保存流程执行期间发生过的事实，已完成实例结束后仍然保留。HistoryService 可以查询历史任务、历史流程实例和历史身份链接，但这些记录不是通用的业务 ACL。

因此建议再增加三类业务数据：交接批次、交接明细和阅读授权。交接批次记录离职员工、接收人、审批人、范围和状态；交接明细记录每个任务处理前后的值与结果；阅读授权记录接收人可以查看哪些流程或业务单据，以及何时到期。

员工账号停用前应该盘点什么

盘点必须发生在移除部门、岗位、角色和群组成员关系之前。否则系统无法还原员工原本通过哪些组织关系获得候选资格。

建议生成一份不可变交接快照，至少包括：

1. 直接分配给离职员工的活动任务。
2. 离职员工拥有的活动任务。
3. 以该员工为候选用户的未认领任务。
4. 通过部门、岗位、角色和动态关系获得的候选任务。
5. 处于委托状态且 owner 或 assignee 为该员工的任务。
6. 离职员工发起但尚未结束的流程。
7. 离职员工已完成的任务、抄送和传阅记录。
8. 关联业务单据、附件、评论和数据权限范围。

盘点结果应按租户、流程类型、业务部门和密级过滤。接收人不能因为接手一个普通报销待办，就自动获得离职员工全部合同、人事和财务记录。

三、模型架构与运行机制

不同任务类型应该采用什么移交策略

任务类型	推荐动作	是否修改 Flowable 运行时数据
直接分配待办	永久改派给接收人	是，修改 assignee
未认领候选用户任务	替换候选用户或保留其他候选人	是，调整 IdentityLink
候选组任务	调整组织成员关系，必要时补充候选人	通常不逐任务修改
普通临时委托	保留 owner，接收人处理后返回 owner	是，使用委托语义
永久离职交接	责任永久转移，不应等待返回离职员工	是，使用改派并校正 owner
已完成任务	保留原办理人，新增阅读授权	否，不改历史事实
抄送、传阅	按授权范围重新授予阅读权限	通常由业务权限层处理

这张表的核心判断是：接收人是在“代为办理”，还是“永久接管”。临时休假适合委托，员工离职通常适合改派。两种操作不能只因为界面都叫“转交”就共用同一实现。

直接分配的待办如何批量改派

Flowable 官方 TaskService.setAssignee(taskId, userId) 用于变更任务 assignee。官方同时说明，该方法不会校验用户是否真实存在于身份组件，因此业务系统必须先验证接收人账号有效、属于同一租户、具备节点办理资格和必要的数据权限。

典型查询从直接分配任务开始：

List<Task> tasks = taskService.createTaskQuery()
    .taskAssignee(leavingUserId)
    .active()
    .orderByTaskCreateTime().asc()
    .listPage(offset, pageSize);

执行改派时，每个任务都要再次确认仍然存在、assignee 仍是离职员工、流程未结束且不在排除清单，然后再调用：

taskService.setAssignee(task.getId(), successorUserId);
taskService.addComment(task.getId(), task.getProcessInstanceId(), handoverNote);

不建议直接批量更新 ACT_RU_TASK.ASSIGNEE_。引擎 API能够维护历史、身份关系和事件监听链；直接 SQL 容易遗漏 ACT_HI_TASKINST 当前快照、IdentityLink、任务分配事件和平台缓存，也难以逐项审计失败原因。

四、核心场景与处理策略

候选用户和候选组任务如何处理

未认领任务没有 assignee，不能使用“把 assignee 从 A 改成 B”的思路。若离职员工是显式候选用户，可以先给接收人增加候选资格，再删除离职员工的候选资格；顺序上先加后删，避免短暂出现无人可认领。

如果候选资格来自部门、角色或岗位，优先在统一身份与组织系统中调整成员关系。任务模型引用的是“财务复核岗”，员工离职后只需让接收人进入该岗位，存量和未来任务都能按相同规则办理。逐任务复制候选用户会造成组织权限与任务权限两套口径。

但交接快照必须保留离职员工退出前的群组关系。Flowable 的候选查询可能依赖身份组件或调用方传入的候选组；一旦先删除成员关系，再查询“该员工原来能认领哪些任务”，结果可能不完整。

对于多人候选任务，还要决定是否真的需要交接。如果同组仍有其他有效候选人，移除离职员工即可；如果接收人不属于该组，却被临时授予候选权，需要设置有效期并记录审批依据。

委托状态为什么需要单独处理

Flowable 的 delegateTask 不是普通改派。官方 API说明：委托时，新用户成为 assignee，任务进入 DelegationState.PENDING；如果原任务没有 owner，原 assignee 会成为 owner。受托人处理后调用 resolveTask，任务返回 owner，而不是直接完成流程。

因此离职场景至少有两种情况：

• 离职员工是 owner，任务已委托给其他人。若不处理 owner，受托人 resolve 后任务会返回已经离职的账号。应把 owner 迁移给新责任人，或者按业务决定把委托转成永久交接。
• 离职员工是当前受托 assignee。可以把 PENDING 委托任务改给新的受托人，但必须保留真实 owner；如果业务决定永久接管，应先结束原委托语义，再建立新的责任关系。

不要对所有离职待办调用 delegateTask。员工已经永久离开时，未来不存在“处理完再还给原责任人”的业务前提。错误使用委托会让任务长期处于 PENDING，普通 complete 还可能因委托未 resolve 而失败。

五、数据、规则与状态设计

会签、并行、子流程和挂起任务有什么特殊情况

多实例会签中，每个活动会签任务都是独立任务。只需要改派属于离职员工的那一个实例，不能删除多实例执行，也不能修改完成计数。改派不会自动改变会签通过比例、完成条件或其他会签人的任务。

并行网关后的多个待办也要分别判断责任人。员工可能同时拥有采购、法务两个分支，两个任务都应进入交接清单，但任何一个改派都不应合并或跳过其他分支。

子流程任务可能属于被调用流程实例，交接日志要同时保存当前任务、子流程实例和根流程实例，便于接收人在门户中看到完整上下文。

挂起流程和挂起任务可以进入盘点，但不建议无提示地自动处理。应标记为“待恢复后交接”或由管理员明确授权，因为挂起通常代表系统维护、争议冻结或业务暂停。

批量交接应该如何设计执行流程

推荐采用“先预览、后审批、再执行”的批次模式：

1. 创建交接申请，指定离职员工、接收人、生效时间和业务范围。
2. 冻结离职员工的登录能力，但暂不删除组织关系。
3. 生成任务与权限快照，按任务类型给出处理建议。
4. 业务负责人、数据负责人和必要的合规人员审批交接范围。
5. 以小批次执行运行时任务改派，并逐项记录结果。
6. 创建已办阅读授权，不修改原历史办理人。
7. 对账任务总数、成功数、跳过数和失败数。
8. 移除组织关系和敏感系统权限，最后完成账号停用。

每个交接项使用“交接批次 + 对象类型 + 对象 ID + 目标用户”作为幂等键。重复执行同一批次时，已经成功且当前状态仍一致的项目直接跳过；失败项目可以单独重试，不需要回滚整个批次。

六、工程实现与系统集成

为什么不能用一个大事务处理几千条任务

任务交接期间，原办理人可能刚好完成任务，管理员可能终止流程，定时器也可能推动流程继续。把几千条任务放在一个数据库事务中，会造成锁持有时间过长、回滚成本高和乐观锁冲突集中爆发。

推荐每批处理 100 到 500 条，或者每个任务使用独立短事务。具体批量大小应根据任务监听器、审计写入、数据库性能和高峰并发压测确定。

每个任务执行前重新读取并校验：

• 任务是否仍然活动。
• 当前 assignee、owner 和 delegation state 是否与快照一致。
• 接收人是否仍有效并具备租户和业务权限。
• 流程实例、业务单据是否已经终止、撤销或冻结。
• 当前任务是否被另一个交接批次占用。

若状态已经变化，应记录为“并发跳过”而不是强制覆盖。失败重试也必须重新校验，不能拿旧快照直接写入。

已办任务阅读权限应该怎样实现

Flowable 的 HistoricTaskInstanceQuery 可以按原办理人查询已完成任务，例如 finished().taskAssignee(leavingUserId)；历史流程查询也支持 involved user 条件。这些 API适合查找原员工参与过哪些流程，但不会自动替接收人建立业务阅读权限。

推荐建立独立阅读授权记录，至少包含：

字段	含义
授权对象	流程实例、任务、业务单据或受控范围
被授权人	接收员工或接收岗位
权限类型	查看轨迹、查看意见、查看附件、下载附件
授权来源	离职交接批次及审批单
有效期	永久、指定日期或接任岗位期间
数据范围	租户、组织、业务类型和密级
撤销信息	撤销人、时间和原因

查询“移交给我的已办”时，先从授权表得到允许访问的流程或业务单据范围，再通过 HistoryService 获取任务轨迹。展示层仍应标明“原办理人：离职员工”“当前阅读授权：接收人”，不能把两种身份混在一起。

阅读权限还应细分。接收人可能需要查看审批结论，却不一定有权下载身份证、薪资附件或涉密合同。附件、评论和表单数据都要继续经过原业务数据权限校验。

七、安全、性能与治理要求

为什么不能修改历史表中的办理人

把 ACT_HI_TASKINST.ASSIGNEE_ 从离职员工更新为接收人，看似能让接收人的“已办”列表立即出现记录，实际上改变了谁完成任务这一审计事实。

这种做法会带来四类问题：

• 审批意见签名、操作日志与历史办理人互相矛盾。
• 合规审计无法证明当时的真实责任人。
• 流程统计、绩效数据和电子签章关联失真。
• 升级 Flowable 或执行历史清理时，自定义改写难以维护。

历史身份链接同样主要表示流程运行时已经发生过的身份关系，不应被当成企业文档 ACL 的唯一来源。阅读授权是当前访问策略，历史记录是过去事实，二者生命周期不同。

如何保证流程状态和业务权限一致

一次完整交接同时影响 Flowable、组织系统、业务单据权限、门户待办索引和消息订阅，通常无法依靠一个本地事务覆盖所有系统。

建议采用批次状态机和最终一致性：待预览 → 待审批 → 执行中 → 部分成功/成功 → 已复核 → 已关闭。每个交接项保存自己的状态，Flowable 改派成功后写入可靠事件，再由消费者刷新门户索引、消息订阅和业务权限。

对账不能只比较“接口返回成功”。应再次查询离职员工仍直接负责的活动任务、仍作为 owner 的委托任务和未完成的失败项目。只有剩余数量为零或全部进入经批准的例外清单，批次才能关闭。

账号停用顺序也要分层：先禁止登录和新令牌，避免离职员工继续操作；保留只供盘点使用的组织快照；任务与权限交接完成后，再移除岗位、群组、接口密钥和外部系统权限。

八、平台落地、测试与选型

交接审计、回滚和异常处理怎么做

交接日志至少保存：批次、源用户、目标用户、任务或流程 ID、交接前 assignee/owner/委托状态、交接后值、操作人、审批单、时间、结果和异常摘要。

运行时任务可以受控回滚，但必须满足：任务仍然活动、当前办理人仍是本批次接收人、没有在交接后发生新的委托或办理动作。否则自动回滚可能覆盖真实业务变化，应转人工处理。

已办阅读授权的回滚更简单：撤销授权记录并刷新权限缓存，但不删除原审批历史。若授权期间接收人已经下载过附件，系统还应保留访问日志，不能假设撤销权限等于数据从未被访问。

常见异常包括接收人账号失效、任务在执行中完成、跨租户目标、委托 owner 缺失、流程挂起和权限索引刷新失败。每种异常都要有明确状态和处理人，不能只把失败堆栈留在日志文件中。

低代码工作流平台还应该提供哪些能力

离职交接不应由管理员临时运行脚本。平台可以提供可视化交接中心，展示待办、候选任务、委托任务、在途流程、已办记录和数据密级，并支持按流程类型批量选择不同接收人。

云程低代码平台这类企业流程产品，还可以把用户、部门、角色、岗位和动态关系办理人统一纳入交接规则：普通报销移交岗位接任人，合同审批移交指定法务负责人，高密级人事流程必须由数据负责人重新授权。

从源头上，应尽量让 BPMN 模型引用稳定的岗位、角色和动态关系，而不是把具体员工账号硬编码在流程定义中。员工变化时，候选资格可随组织关系自然更新；只有已经认领或直接分配的存量任务需要迁移。

九、如果只记住三句话

第一，员工离职通常是永久改派，不是临时委托；直接待办使用 Flowable 任务 API逐项迁移。

第二，已办任务的原办理人是历史事实，接收人需要的是阅读授权，不是把历史 assignee 改成自己。

第三，批量交接必须先快照和分类，再分批执行、对账和审计，不能依靠一条 SQL 或一个超大事务。