离职信息靠人工逐级通知
HR 更新状态后，管理员仍需联系目录、办公平台和业务应用负责人分别处理。
场景解决方案 / 全域数字身份治理解决方案
员工离职后回收账号与应用权限
让离职状态进入明确的账号处理流程，并逐个核实已接入系统的执行结果。
统一身份账号停用不自动代表所有下游应用权限均已回收；每个目标系统的动作取决于接口与企业规则。
客户问题
人员离职状态更新后，账号和访问处理仍可能分散
风险不只在触发是否及时，也在目标系统是否执行以及失败后由谁跟进。
只记录请求，未核对实际结果
接口失败或目标系统无响应时，如果只看到流程已提交，管理员无法确认账号是否仍可登录。
整体思路
从权威离职状态到逐系统结果核验
以企业确定的人员主数据状态为触发依据，按经接入的系统范围执行约定的账号处理动作。数犀集成平台可编排已确认的连接步骤；应用内角色、业务权限和未接入系统仍由各系统责任人处理。
- 01人员主数据确认离职状态与生效时间
- 02数犀集成平台匹配人员并执行已配置的下游动作
- 03已接入系统返回或记录执行结果
- 04管理员复核确认失败项及未接入范围
下游权限回收不能从身份同步动作自动推定；需区分账号禁用、应用角色清理和数据权限处置。
核心任务
根据权威状态启动账号处理 · 追踪各系统的处理结果
01 / 根据权威状态启动账号处理
明确人员匹配与触发时点
- 01HR / 主数据记录离职及生效信息
- 02人员匹配以唯一标识定位账户
- 03身份目录执行约定的账号状态动作
原来怎么处理
HR 更新离职状态后，相关管理员收到通知，再分别登录多个系统查找员工账号。
数犀如何处理
在确认源端状态、人员标识和动作范围后，触发统一身份侧及已接入目标的约定处理。错误离职记录必须有企业定义的恢复路径。
用离职、延期生效、同名或错误人员标识等测试情形检查触发时点与匹配对象，并验证恢复流程。
希望带来的变化
减少逐系统发通知的重复步骤，同时把处理对象和动作依据说清楚。
相关能力人员状态同步身份账号停用连接流编排
02 / 追踪各系统的处理结果
失败时留出人工处置路径
- 01目标系统调用按接口执行停用或更新
- 02执行结果成功、失败或待人工
- 03管理员复核核对未完成项与目标状态
原来怎么处理
管理员可能只看到“已发起”，却不知道 AD、钉钉或业务应用是否已执行；应用权限仍需逐个核对。
数犀如何处理
对每个已接入目标记录返回结果；失败时按责任划分重试或转交目标系统管理员。没有接口或不在范围内的权限，明确列为人工处理。
制造一个目标接口拒绝或超时，检查记录是否能显示未完成项；再到目标应用验证实际登录和角色状态。
希望带来的变化
让“请求发出”与“目标账号已处理”可被区分，便于完成未结项跟踪。
相关能力执行日志异常处理目标状态核对
改善与验证
验证离职触发、目标状态与恢复边界
使用隔离的测试账号和已确认的系统范围，逐项记录执行事实。
| 常见处理 | 希望实现的变化 | 试点检查方法 |
|---|---|---|
| 逐系统通知HR 更新状态后，管理员仍需联系目录、办公平台和业务应用负责人分别处理。 | 希望实现的变化离职状态触发已配置的目标处理，并可识别未接入系统。 | 试点检查方法演练测试员工离职，核对每个已接入系统的执行记录和目标账号状态。 |
| 不完整回收接口失败或目标系统无响应时，如果只看到流程已提交，管理员无法确认账号是否仍可登录。 | 希望实现的变化失败项进入可追踪的人工处理，不以提交成功冒充回收完成。 | 试点检查方法构造接口超时或权限不足，验证错误提示、责任人、重试和更正离职后的恢复步骤。 |
本页不承诺一次操作回收所有应用角色、共享账号、数据权限或第三方 SaaS 凭据；这些需要目标系统接口和业务规则支持。
