基于简道云名单的企业微信成员删除同步方案

这个策略解决什么问题

某零售企业的 HR 把离职流程放在简道云表单里走审批,但企业微信侧成员要靠管理员手动删。一个月下来,经常出现"人已离职但企业微信还在通讯录里"的情况,既影响考勤归档,也带来数据合规风险。这个策略只解决一件事:以简道云表单为唯一真相源,当成员状态变成待注销时,自动调用企业微信删除接口,把成员生命周期闭环做掉。

数据流向与字段映射

整个链路是单向的:简道云(源) → 轻易云数据集成平台(编排) → 企业微信(目标)。

源端(简道云)是一个表单,关键字段包括员工 userid、企业微信 userid、状态、最后更新时间。目标端(企业微信)只有一个入参:userid,通过 /cgi-bin/user/delete 删除对应成员。

维度	简道云(源)	企业微信(目标)	映射说明
关键字段	状态(枚举:在职/待注销/已注销)	—	增量过滤条件,只处理"待注销"
业务字段	企业微信 userid	`userid`(string)	1:1 直传,作为删除入参
业务字段	员工工号	—	仅做日志与回溯,不入参
业务字段	离职时间	—	仅做日志与回溯
响应判定	—	`errcode`	轻易云按 `errcode==0` 判定成功

提示:实际项目里我们经常见到一种简单但容易翻车的做法——直接把"姓名"当 userid。姓名是会重复的,userid 才是企业微信里的唯一键。稳妥的做法是让 HR 在表单里单独维护一列企业微信 userid,并通过 OCR 或 API 一次性导入,轻易云侧只做直传。

在轻易云上如何配置

源端(简道云)

接口:POST /api/v2/app/{app_id}/entry/{entry_id}/data,类型 QUERY,
入参重点:appId 指向"成员名册"应用,entryId 指向对应的表单,fields 显式列出 userid,status,updated_at,limit 给到 100。
调度:3 5 * * *(每天凌晨 5:03 拉一次),用 updated_at > 上次成功时间 作为增量条件。
关键开关:idCheck=true,buildModel=false。前者保证记录可定位,后者避免轻易云把表单结构建进模型干扰后续维护。

目标端(企业微信)

接口:POST /cgi-bin/user/delete,类型 WebAPI / EXECUTE,
入参:userid 绑定源端的"企业微信 userid"字段。
响应判定:把 errcode 配成 statusKey,成功值填 0。
调度:23 1 * * *,故意排在源端调度之后 20 分钟,确保拿到的就是当天的最新状态。

编排层(轻易云)

编码映射集中管理:userid 是横跨两个系统的"硬键",我们在轻易云的映射中心单独维护一张映射表,新员工入职时 HR 同步录入,避免源端脏数据污染下游。
失败重试:删除接口偶发返回 60011(网络忙)或 60020(名字冲突),轻易云默认重试 3 次,间隔指数退避。
人工兜底:连续重试仍失败的记录,写入"异常队列",由 HR 在简道云另一张异常表里手工确认后,再触发一次删除或选择跳过。

实施步骤

我们把上线过程拆成四段,稳妥推进。

资料与权限准备:拿到简道云应用的 appId、entryId 和企业微信的通讯录管理 secret,在轻易云的凭证管理里分别录入,凭证不落地到任何脚本。
全量对账(一次性):先用轻易云跑一次全量,把当前"在职"和"待注销"两类数据拉出来,与企业微信通讯录做交叉比对,补齐缺失的 userid。这一步是后面所有自动化的地基。
灰度上线:策略先只对"待注销"中一个测试员工跑,人工确认企业微信侧真的被删掉后再放开。轻易云的灰度开关按工号前缀过滤即可。
全量与增量双轨:历史数据补完后,源端进入增量模式(updated_at 过滤),目标端按调度删除。运行两周后,把人工兜底改成"仅告警、不阻断"。

踩坑复盘

状态字段是中文枚举,轻易云侧不要硬编码字符串:某次客户把"待注销"改成了"待离职",源端过滤直接失效。我们后来统一改成映射表里的状态码,中文只做展示。
userid 在企业微信里全局唯一,但简道云表单可以被多次提交:同一个离职员工可能产生两条记录,都进了删除链路,后者会因账号已不存在返回 60111。稳妥做法是在轻易云里加一层去重,只保留最新一条。
删除是不可逆操作,一定要先关掉自动邀请:如果企业微信侧开启了"成员被删除后自动回收并邀请同名成员",会出现刚删完又建回来的诡异现象。客户的做法是先把回收策略关掉,删除完成后再单独处理账号池。
凌晨调度撞上企业微信维护窗口:每天 1:23 这条策略偶尔遇到 5xx 抖动,我们后来把目标端挪到 1:23 之前、源端挪到 5:03 这个企业微信低峰期。
不要用同一份源数据同时驱动多个删除策略:同一个表单如果被多条策略引用,容易出现并发删除冲突。我们建议在轻易云里把"删除成员"和"禁用成员"拆成两条独立策略,各自跑自己的增量。

适用场景与不适用场景

适用:HR 在简道云里走完整离职审批,企业微信是企业唯一的 IM 与考勤工具,日均离职 0–10 人,成员状态字段是结构化的枚举。 不适用:成员关系跨多套企业微信、需要按部门级联删除、简道云表单没有强制结构化状态,或者"删除"动作本身需要走二级审批。这些场景应该升级为"禁用成员 + 待人工确认"的软删除方案,而不是直接走硬删。