OA审批人离职以后，最容易出现的错误是立即停用账号，却没有检查他正在承担的审批和业务角色。正确处理方式不是一个“转交按钮”就能概括，而是把已经运行的流程、新发流程、角色关系和数据权限分别盘点，再根据企业当前OA版本和管理制度选择对应处理办法。
一个员工可能同时是：
如果只按照HR系统里的“离职员工”处理，可能遗漏他在工作流和业务模块中的其他身份。
所以离职前最好先做一次：
人员—角色—流程—权限盘点。
例如：
某份合同已经经过业务、法务等环节，现在正等待即将离职的负责人处理。
这时候存在两类问题。
第一类是：
这张已经运行中的单据由谁继续处理？
第二类是：
明天新发起的合同应该由谁审批？
二者必须分开。
企业需要根据现有OA版本的流程管理、代理、委托或管理员处理机制，以及自身审批制度确定在途单据如何交接。
这里不建议简单修改流程模板以后就算完成，因为模板变化通常首先影响未来新发起的流程，并不天然等同于已经运行中的所有单据都被重新分配。
如果流程长期写成：
张三审批。
张三离职以后，就要人工修改。
更容易维护的设计是：
所属部门负责人审批； 财务负责人审批； 项目负责人审批。
也就是把人员关系尽量抽象成：
组织 → 岗位 → 角色 → 流程
这样人员调整以后，新流程更容易沿新的组织和岗位关系运行。
假设新负责人已经能够审批，却发现：
看不到合同附件和项目数据。
流程依然无法正常办理。
这说明审批权限和数据权限不是一回事。
离职交接时至少要检查：
同时还要避免原人员离职后仍保留不必要访问权限。
OA还有一个重要要求：
人员变了，历史责任链不能消失。
已经完成的审批记录应该继续反映当时实际是谁办理、何时办理，而不是因为新负责人上任，就把过去的责任记录改成新负责人。
这也是流程审计和业务追溯的基础。
重要岗位员工离职时，建议至少检查：
华天动力OA过去产品和项目资料中已经存在审批管理、代理等相关机制，但对于“当前版本如何处理某一类在途审批”，正式项目中仍应根据具体版本和流程设置确认，不能把所有离职场景简单归结为一种处理方法。
真正成熟的工作流设计，需要从一开始就接受一个事实：
人员会离职，岗位会变化，组织会调整。
因此，企业评估OA工作流时，不妨把“审批负责人突然离职”直接作为演示题。能否清楚区分在途流程、新流程、角色和权限，比单纯演示一条正常审批路径更能看出系统的长期治理能力。
