只同步一组已经约定的客户字段
本例将客户系统的编号、简称、联系人同步到订单登记工具。客户系统负责维护这三个字段，订单工具的内部备注与订单记录不由同步修改。源客户停用时，目标不再提供新订单选择，但保留已有订单关联。
实施前由系统负责人确认读取与写入范围，准备测试环境和脱敏样本。登录网页可见某项信息，不自动意味着已取得对应接口或批量操作权限；实际能力以系统提供的接口和已授予权限为准。
先预览每条记录会发生什么
| 源编号 | 目标现状 | 计划动作 |
|---|---|---|
| C001 | 有一条匹配记录，联系人已变化 | 更新联系人，保留目标内部备注 |
| C002 | 有两条同编号记录 | 冲突，暂不写入 |
| C003 | 没有匹配记录 | 新建，并保存源/目标编号关系 |
本例按稳定的来源编号匹配，不按公司简称近似匹配。源字段未提供、提供空值与要求清空是三个不同情况：应按字段约定处理，不能把缺字段当成删除现有联系人。
写入超时进入“待确认”，先查询结果
运行后，C001更新成功，C002保持冲突；C003的新增请求超时。此时批次显示更新成功1条、冲突1条、结果待确认1条。C003可能已经在目标保存，不能立即再次新增。
按接口支持的方式，使用来源编号或请求编号查询。查到目标T105已创建C003时，核对字段后补记映射，C003转为新建成功。若仍无法确认，继续保留待确认状态，由负责人核查。Microsoft的API设计文档指出POST、PATCH不保证重复调用没有额外副作用，因此重试应遵守该接口的去重约定。
批次结束要核对业务结果
本例最终为处理3条：更新1条、新建1条、冲突1条。冲突C002仍需要目标资料负责人处理，不能把整批标为无异常完成。每条成功记录保存源编号、目标编号、变更字段和时间，便于从两个系统互相回查。
下一批遇到相同数据时，不再新建C001或C003。目标内部备注如果已被工作人员修改，同步仍按字段维护约定保留它。读取列表涉及多页时，还应核对本批来源范围与页数，防止只处理第一页却报告全部同步。
用重复运行和人工修改做最后验证
重复执行原批次，核对目标没有新增重复客户；人工修改目标备注，再同步C001，确认备注保留；制造C002同号冲突，确认两条记录都不被随意覆盖；模拟C003响应中断，核对查询后只形成一条客户。方案完成的标志是每条数据的结果可解释，而不只是接口返回过成功。