第一期系统要不要对接钉钉企业微信或OA?
结论:企业协作平台是不是一期接入,只看它是否是核心流程的必要前置条件。
如果员工必须从钉钉、企业微信或 OA 登录,部门与主管决定数据权限,或审批结果直接影响业务状态,一期不接就无法真实验收;如果只是把通知推到群里、增加工作台入口或减少一次登录,则可以在独立闭环稳定后接入。滚水科技不会统一建议全部放到二期。
在比较平台能力、限制与迁移成本时,还可以对照 我该做 App、小程序还是网页?怎么判断? 和 官网、H5、管理后台、小程序和 App 可以统一规划吗?;这些内容补充了需要放在同一项决策中考虑的上下文。
用“拿掉集成还能不能工作”做判断
先画出员工、组织、角色、审批、消息和业务数据之间的依赖。如果去掉外部平台后,用户仍能合法登录、找到待办、完成决策且数据不重复维护,集成是体验增强;如果系统不知道谁是主管、审批结果无法生效或企业安全制度禁止独立账号,它就是一期范围。
| 集成能力 | 一期接入的条件 | 可后置的条件 | 主要技术风险 |
|---|---|---|---|
| 单点登录/免登 | 企业规定唯一入口或账号生命周期必须统一 | 允许独立账号且首期用户少 | 身份绑定错误、离职未撤权、令牌泄露 |
| 组织与人员同步 | 部门/汇报线直接决定权限和流程 | 角色可由少量管理员维护 | 主数据冲突、删除语义、重复账号 |
| 审批/OA 联动 | 审批结果是订单、合同等核心状态前置 | 首期可在本系统完成审批 | 双向状态不一致、重复回调、撤回补偿 |
| 消息与待办 | 不推送就无法及时履约或达到 SLA | 用户可在系统内查看且频率低 | 重复、顺序、限流、敏感信息外泄 |
| 工作台入口 | 企业终端只允许从该入口访问 | 可用网址/客户端进入 | 平台容器兼容和导航差异 |
对接之前先决定谁是主数据源
员工编号、手机号、部门和岗位不能在两个系统中互相覆盖。每个字段指定 source of truth:通常企业目录负责人员在离职状态和组织关系,业务系统负责业务角色与授权范围。同步要定义新增、变更、停用、恢复、部门合并和临时接口失败;“删除员工”往往应转为停用并保留历史业务记录。
标准化设计可借鉴 SCIM 协议 RFC 7644对用户和组资源、过滤、批量及错误响应的定义,即便具体平台不直接支持 SCIM,也能帮助明确目录同步契约。授权流程则要遵循平台官方文档和 OAuth 安全要求;OAuth 2.0 Security Best Current Practice(RFC 9700)总结了当前常见攻击与防护,但具体免登、回调签名和权限范围仍以目标平台控制台为准。
项目启动时,客户应提供目标平台、企业管理员、应用类型、可用测试组织和内部审批时限。滚水科技会在钉钉开放平台或企业微信开发者中心当前文档中核对授权、通讯录、回调与消息能力,不把另一个客户的字段和权限直接复制过来。自建 OA 则必须取得实际接口、样例和测试环境。
一期集成也应克制边界
即使必须接,也不代表一次同步全部通讯录、审批和消息。首期只接核心流程所需的最小字段和事件,例如登录身份、在职状态、部门 ID 与一个审批结果;薪资、私人手机号或无关部门数据不因接口可取就采集。业务权限不应仅依赖易变的部门名称,使用稳定 ID 并记录映射版本。
验收要模拟真实变化:新员工首次登录、员工调岗、离职撤权、部门改名、同一手机号冲突、回调重复/乱序、平台超时、令牌失效和补偿重放。每条同步有外部事件 ID、幂等结果和审计日志;定期全量对账发现漏事件。消息成功调用 API 不等于用户已读,不能据此证明业务完成。
若后置到二期,一期仍要预留稳定的内部用户 ID、组织映射表和事件接口,而不是把手机号直接当永久主键。第二期开始前用真实测试租户验证权限和限额,再更新排期。具体周期由客户制度、平台权限、组织数据质量和接入范围共同决定,我们会在完成接口与测试租户验证后给出排期。
滚水科技最终交付字段映射、权限范围、回调契约、同步补偿、测试证据、管理员操作和故障手册。平台账号由客户控制,我方使用最小权限开发身份;停止合作或更换平台时,客户能撤销应用授权并导出映射关系。