模板能降低开始使用的成本，却也会产生一个长期问题：用得越久，本地做法越不同于最初来源。字段被改过，流程增加了阶段，看板也形成了自己的口径。
这些变化通常正是模板有用的结果。若升级要求放弃它们，用户就会在继续更新与保留业务之间被迫选择；若永远停在第一次导入，又无法继续取得来源的改进。
升级因此需要合并两种都有价值的变化。Teloa 在业务配置与看板模板中同时比较原来源、本地当前版与候选新版，辨认改动来自哪里，再用现有记录检查采用后的含义。
为什么需要同时看三份内容
只比较本地和新版，可以看见差异，却不知道差异来自谁。一个字段名称不同，可能是用户有意修改，也可能是上游更新；两种情况不应采用相同覆盖方式。
三份内容各自回答一个问题：
| 比较对象 | 要辨认的变化 |
|---|---|
| 原来源版 | 最初采用了什么 |
| 本地当前版 | 采用后自己改了什么 |
| 候选新版 | 上游又增加或修改了什么 |
三方比较帮助辨认可合并变化与冲突，让用户不必凭记忆还原半年前的配置。
假设上游增加了“待补充条件”，本地已有“内部复核”。两者可能共同保留；如果双方都修改同一个阶段的含义，就需要具体决定，不能只按名称合并。
预览因此要落到对象、字段、状态与关联关系，而不是只显示“有新版本”。升级改变的是日常工作定义，用户需要理解具体影响。
配置正确，不代表旧记录仍然成立
新版自身可以通过结构校验，却让已有数据失去合法含义。缩小状态选项、删除字段、改变类型，都会影响已经在用的记录。
当前影响检查读取相关历史，指出受影响字段与记录数量，阻止不兼容的有损采用。草案可以保留，先处理数据和定义之间的关系，而不是为了完成升级丢掉旧值。
归档旧记录也不能自动免除影响，因为历史仍然需要解释。一个阶段不再用于新事项，不等于过去处于该阶段的客户就失去保存价值。
配置合并和数据兼容是两种独立检查。上游新增字段而本地改了名称，定义可能可以合并；新版删除一个仍被历史记录使用的状态，即使没有配置冲突，也存在数据损失。三方比较解决“改动来自谁”，记录影响解决“采用以后会伤到什么”。
这种升级比重新导入多了步骤，却让定制和持续更新可以共存。企业不用为了收到改进而放弃自己的做法，也不用为了保护旧记录永远停留在最初模板。
预览和采用之间，事实还会变化
用户看完预览后，另一处可能新增或修改记录。几分钟前没有影响，不说明此刻仍然安全。实际采用需要核对当前版本和依赖，旧预览不能无限有效。
需要重新预览时，原草案仍然保留，用户只需面对变化后的影响重新决定。采用状态按原回执核对，避免等待和中断使同一次升级重复发生。
这些处理使升级可以经历正常等待和中断，而不用要求用户一直守着页面。系统保存原意图与结果，人负责选择采用的内容，两者各有明确位置。
新增持续规则仍需单独启用。接受了一份更好的配置，不表示用户愿意立刻增加后台工作和消耗，配置变更不能顺手代替运行决定。
恢复旧模板，不是回到过去的业务
恢复旧配置同样需要面对现在的数据。用户希望回到熟悉的方法，不意味着最近发生的客户活动、任务和成果应当消失。恢复因此仍经过合并、预览和采用，旧定义能否容纳当前记录也要检查。
模板由此可以成为长期来源，而不是一次性起点。用户既能取得共同改进，也有权继续形成自己的做法；两者的冲突需要显现并处理，不能由一次更新替人作出选择。