员工入职/离职时，用企微 API 自动更新通讯录和账号

先说一个容易走错的前提开放实例 API 里的通讯录是读的方向contact/getSyncList拉的是企微里已有的组织节点没有往企微通讯录里加人的写接口。想直接在企微后台建账号得走企业微信官方企业内部应用那套。所以这篇讲的自动化落点不在往企微写人而在接住企微侧的组织变化把连锁动作做完建账号、发欢迎、分客户、清会话、转移客户。入职这条链企微侧账号建好之后你系统这边要做四件事顺序不能乱。第一步同步到本地。定时增量拉一次或者等成员变更的事件回调。判断新人靠uin在本地表里不存在。第二步建业务账号。用uin做关联键把工号、部门、直属上级写进本地表。别用手机号做主键重号和换号都会出问题。第三步发欢迎消息。这一步容易被跳过但员工对企业的第一印象常常来自这里。内容不用长三条就够所在部门、直属上级、遇到问题找谁。def onboard(uin): profile fetch_profile(uin) db.upsert_user(uinuin, nameprofile[name], dept_idsprofile[deptIds], status1) conv_id resolve_conversation(uin) send_text(conv_id, ( f欢迎加入 {profile[deptName]}。\n f你的直属上级是 {profile[leaderName]}。\n f内部系统账号已开通首次登录请修改初始密码。 ))第四步加进该进的群。按部门或项目映射到群 id调room/addGroupMember拉进群。这一步最容易出事——群 id 写错就把新人拉进无关的群所以群映射要配成表别写在代码里。离职这条链离职比入职麻烦因为牵扯到数据和客户。感知离职。增量同步里成员节点的status变成停用或者节点被标记删除。别指望能立刻收到通常有几小时到一天的延迟所以业务上要能容忍已离职但仍能登录这个短暂窗口。停用业务账号。这一步要立刻做别等同步周期。做法是在本地表上先按 HR 事件标记下来同步到了再确认。处理客户归属。员工名下的外部客户需要转移这属于客户继承的范畴操作在企微管理后台完成你系统这边负责提醒和记录def offboard(uin): db.update_user(uinuin, status0, left_atnow()) customers db.query_customers_of(uin) if customers: notify_hr_and_leader( f{db.get_name(uin)} 已离职名下 {len(customers)} 个客户待分配 f请在企微后台完成继承。 ) clear_session_cache(uin)清缓存。会话 id、Token、群成员缓存里都可能有这个人的痕迹。不清的话后面的推送任务可能还会往一个失效会话里发每次都要等超时。群成员处理。离职的人如果还在群里客户会看到。定期核对群成员列表发现离职但仍在本群的提醒群主移除。两件让这套东西稳下来的事事件和定时双轨。只靠回调丢一条就漏一个人只靠定时延迟可能到一天。两者都做回调负责及时定时负责兜底。每天做一次对账。拿本地表的在职人数和通讯录里的成员数比一比数量不一致就打日志告警。差异通常来自离职没感知、新人没同步、重复记录。对账是最后一道防线。一个真实的节奏某公司把这套东西跑起来之后新人从入职当天手动开五个系统的账号变成到岗前账号已就绪第一天上企微就收到欢迎消息。离职从等人走了才想起来停权限变成当天自动停用客户转移有提醒。省下来的不是开发时间是那种总怕漏了谁的心力。真正要花心思的是那几条连锁动作的顺序和边界——接口调用本身只占很小一部分。