《Ecology9——飞书账号与部门自动化》
飞书账号与部门自动化
内部文档 · 面向产品与研发对齐
一、背景
公司使用飞书作为主要 IM 与协同工具。员工入职后需要有飞书账号才能正常办公,离职后账号需及时关闭以防数据泄露。与此同时,公司组织架构在飞书侧频繁调整,OA 侧的部门数据却长期依赖人工同步,经常出现两边不一致的情况。
主要问题:
- 入职开号慢:IT 需要人工在飞书后台创建账号,新员工第一天经常没有账号
- 离职账号不及时关:存在安全隐患,文档、日历等资源归属不明
- 部门数据两张皮:飞书调整了组织架构,OA 要手动跟着改,容易遗漏
- 新员工拉群靠人工:需要 HR 手动把新人加入公司群、楼层群等
二、目标
- 员工入职审批通过后,自动创建飞书账号并拉入对应群组
- 员工离职后,自动关闭飞书账号并完成 9 类资源的继承交接
- 飞书侧组织架构变更后,OA 部门数据实时自动同步
- 所有操作有失败告警和自动重试机制
三、账号自动化
3.1 入职开号
触发方式一:审批流节点(实时)
- 入职审批通过后立即触发
- 校验 OA 账号是否已创建,若无则跳过并告警
- 调用飞书
contact.v3.user.create创建账号 - 创建成功后:
- 将飞书 OpenId 回写到 OA 人员档案
- 自动拉入公司群
- 女性员工自动拉入女员工群
- 按办公楼层自动拉入对应楼层群
- 向 SOC 推送
ONBOARDING事件,完成账号体系的入职闭环
触发方式二:定时任务(兜底)
- 每日扫描”今日入职”且飞书账号未开通的员工
- 失败时标记状态字段,下次轮询自动重试
- 失败告警推送至系统管理员飞书
3.2 离职关号
- 离职审批通过后触发
- 调用飞书
user.delete,必须指定 9 类资源接收人:- 部门群、外部群、文档、日历、应用、妙记、问卷、邮件、集成平台
- 表单上由 HR 或员工本人在离职流程中填写各类资源的继承人
- 同步关闭 AD 域账号(推送 SOC
USER_DELETE事件)
四、部门自动化
4.1 实时同步(飞书 → OA)
- OA 启动时建立飞书 WebSocket 长连接
- 飞书侧新增/修改/删除部门时,事件实时推送到 OA
- OA 自动更新
hrmdepartment和hrmdepartmentdefined(维护飞书 OpenId 映射)
4.2 定时全量兜底(OA → 飞书)
- 每日定时从飞书递归拉取完整部门树,校对并补全 OA 侧的映射关系
- 用于修复 WebSocket 断连期间漏掉的事件,以及手工调整后的数据修复
五、解决的核心痛点
| 痛点 | 解决方式 |
|---|---|
| 入职没账号 | 审批通过即自动创建,兜底任务扫漏补创 |
| 离职账号不关 | 离职流程自动关号 |
| 资源归属不明 | 离职流程强制填写接收人,飞书接口完成转交 |
| 部门两张皮 | WebSocket 实时同步 + 定时全量保障一致性 |
| 拉群靠人工 | 创建账号后自动按条件拉群 |
六、风险
| 风险 | 说明 |
|---|---|
| WebSocket 断连 | 由定时全量同步兜底,最长延迟一个轮询周期 |
| 飞书 API 限流 | 批量拉群时可能触发,目前无重试队列,靠定时任务补偿 |
| 离职资源接收人未填 | 表单必填规则控制,接收人未填无法提交流程 |

All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.

