用户与部门同步策略实战:从 CRM 到集成平台的一次轻量落地

这个策略解决什么问题

在 CRM 与 ERP 并存的私有化环境里，「人是哪儿的人、归哪个部门」这件事几乎每天都在被业务和 IT 反复确认。一次实际项目中，某制造企业把 CRM 当作销售人员的唯一口径，ERP 当作组织架构和权限的唯一口径。两边用户表一旦没对齐，下游的报销、审批、数据权限就会集体漂移。这条策略的核心目的，是把 CRM 端的用户主数据及其所属部门，定期拉到轻易云数据集成平台做归一，交给后续的基础资料策略继续往下游分发。

数据流向与字段映射

本策略属于「源 → 中间层」的轻量落库，源端是 CRM 用户查询接口，中间层是轻易云数据集成平台，目标端是「写入空操作」占位接口，等待后续策略消费。

关键字段对照如下：

这里特意把「部门名称」和「部门编码」都保留下来。客户现场常见的应对模式之一，就是「编码映射集中管理」：先把名称和编码一起落库，到下游再走一张独立的映射表，避免在每个策略里重复维护。

在轻易云上如何配置

源端策略的元数据是典型的查询型：接口路径 /v1/user/list，GET 请求，分页由轻易云自动接管，单据编号字段设为 nickname，单据 ID 字段设为 user_id，关闭单据存在性校验（idCheck=false），不构建写模型，响应字段按上面那张表定义即可。

目标端先挂一个「写入空操作」的 WebAPI 节点，方法 POST，请求体为空。这样做的目的有两个：一是把数据先稳稳落地到轻易云集成平台；二是给后面的「部门 → ERP 组织」「用户 → ERP 操作员」策略留一个稳定的订阅点，避免一上来就压下游。

配置层面有三个要点值得展开：

第一，源端的 crontab 建议放在凌晨低峰，例如 3 2 * * *；目标端占位策略可以略晚一些，例如 23 2 * * *，给源端留足落库窗口。这是「表头表体分阶段」思路在调度时间上的体现。

第二，轻易云数据集成平台对查询型策略默认不写回源系统，所以这里不需要关心反向同步。

第三，响应字段全部为 string 时，记得在中间层显式声明主键字段，否则下游订阅时会拿不到稳定的去重依据。

实施步骤

我们一般按三阶段推进：

第一阶段：增量起点初始化。全量触发一次，把 CRM 当前在用的用户与部门快照一次性拉进轻易云集成平台。这一步在策略里通过「手动执行 + 全量模式」完成，跑完之后切回增量。

第二阶段：调度频率落地。源策略按天凌晨执行，依赖上一日 CRM 的最终态；目标占位策略在源策略跑完之后延后一段时间执行，承接落库。后续真正分发到 ERP 的策略，再以中间层的数据为起点，按各自节奏跑。

第三阶段：监控与对账。轻易云数据集成平台自带的运行日志可以看每次拉取条数、失败明细；客户现场通常再加一张简单的对账表，比对 CRM 当日用户数与中间层落库数，差异超过阈值就告警。这是「增量与全量双轨」的常见组合：日常跑增量，每周或每月做一次全量兜底。

踩坑复盘

1. 部门字段别只看 department_name。一次实际项目里，客户只拉了名称，下游做组织映射时才发现同名部门在不同业务线各有一个，编码完全不一样，最后只能回溯补字段。稳妥的做法是名称和编码一起落库。

2. user_id 不要当成邮箱用。典型错误是直接把 user_id 当成下游 ERP 操作员编码。一旦 CRM 调整 ID 规则，下游全部失配。中间层只做搬运，不做语义合并。

3. 不要在查询策略里做写操作。该策略类型是 QUERY_ONLY，目标端用了「写入空操作」占位，并不是真的写第三方系统。容易翻车的是有人顺手在源策略里塞一段写脚本，导致查询与写入耦合，后期排查困难。

4. 时区与当日边界。CRM 字段如果带本地时区时间戳，下游按自然日切片时会出现「少一天」或「多一天」。建议在轻易云上统一用服务器时区，并在文档里写清楚。

5. 分页与去重。接口未明确分页字段时，轻易云默认按响应数组长度判定；但若接口偶尔返回重复 user_id，下游订阅会反复处理。稳妥的做法是在中间层显式做一次主键去重。

适用场景与不适用场景

本策略适用于：私有化环境下 CRM 作为用户主数据唯一口径、ERP 需要消费该口径的「源 → 中间层」轻量落库场景。不适用于：CRM 与 ERP 用户口径已经统一在一方、不需要中间层归一的场景，以及对实时性要求极高（如秒级同步权限变更）的场景。