层级与双向数据

🌐 另有 28 种语言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

图片由 AI 生成

由 AI 翻译，尚未经过社区审校。 阅读英文版

第 5 个模块，共 6 个，属于 Data Architect 课程第 6 章主数据与身份。每个模块都可以单独阅读。 上一篇：地图不是决定 · 下一篇：检查点 1：Steve Trucking

**本模块回答的问题：**如何管理由不止一个系统维护的数据？

简单的架构是：ERP 拥有客户，Salesforce 拿到一份副本，完事。真实的企业没有那么干净。ERP 拥有法定客户，Salesforce 拥有销售关系；一个事业部在 SAP 里，一个被收购的事业部在另一个 ERP 里；潜在客户只存在于 Salesforce 中。然后有人希望 Salesforce 用户去更新一个由 ERP 控制的字段，于是箭头开始指向两个方向。正如我讲这一部分时说的：“最难的是双向同步。”不是因为双向发送数据在技术上很难，而是因为一旦两个系统都参与变更，你就必须对权威极其精确。

双向数据不意味着两个主控方

ERP 拥有账单地址，并把它复制到 Salesforce。一位销售代表从客户那里得知地址变了，业务方希望他们无需离开 Salesforce 就能更新它。很合理。现在数据流向是 ERP → Salesforce 和 Salesforce → ERP。Salesforce 现在共同拥有账单地址了吗？没有。**集成的方向并不决定权威。销售代表并不是在修改 Salesforce 的副本。在架构上，他们是在请求修改权威的值。**你不是在修改 ERP 的字段，而是在请求修改它。Salesforce 是界面；ERP 仍然是主控方。

这改变了设计。如果 Salesforce 拥有这个字段，保存就完事了。如果 ERP 拥有它，“保存”就意味着 Salesforce 发送提议的地址，ERP 验证并接受它，更新自己的主数据，再把权威的值发回来。只有到那时，受治理的值才改变了：请求 → 验证 → 接受 → 发布，而不是“更新两个系统，然后祈祷它们保持同步”。

Click to enlarge

双向集成并不会产生双向的权威。

当主控方说不

ERP 拒绝了这次修改：客户不活跃，地址违反了某条 ERP 规则，这个用户不能修改法定地址，ERP 宕机了，或者在此期间有别人修改了这个客户。如果 Salesforce 已经显示了新地址，我们现在就有了两个真相，而模块 1 已经告诉了我们哪个胜出：ERP 的。所以架构需要一个已请求、尚未接受的状态：一个单独的提议值，一个“待处理变更”标志，或者等到确认之后再显示它。机制取决于具体用例。规则不变：永远不要让一个被拒绝的请求变成相互竞争的真相。

循环与冲突

这是一个经典问题。ERP 更新了 Salesforce；Salesforce 的集成看到了一个变更，把它发给 ERP；ERP 看到一次更新，又把它发回来。你建出了一个非常昂贵的循环。好的双向设计知道一个变更从哪里开始，主控方是否已经接受了它，以及这是一个新的业务变更，还是一个已经处理过的变更的回声：源标识符、时间戳、集成元数据、幂等处理。集成那一章会深入讨论。主数据的原则很简单：要知道你是在发起一个变更，还是在反映一个变更。

然后是冲突。你在第 5 章见过一个：一位销售代表要求用 Steve’s Plumbing LLC，而 ERP 里有人输入了 Steve’s Plumbing L.L.C.（保护受治理的记录）。这里再举一个。Salesforce 提议改成 125 Main Street；几乎同时，一位 ERP 用户把它改成了 130。哪个胜出？没有通用的技术答案。也许 ERP 总是胜出，因为它拥有这个字段；也许 Salesforce 的请求进入一个审核队列；也许较晚被接受的变更胜出；也许 ERP 会拒绝任何起始值已经改变的更新。这是并发问题，但在它之下是一个权威决定，而如果没人决定谁可以做出权威的修改，任何集成模式都救不了你。

而单个字段还是简单的情况。一个地址由街道、城市、邮政编码组成。Salesforce 发送了一个新的街道，而 ERP 刚刚修改了城市。你会让街道单独通过吗？还是把地址当作一个事务，让这些字段要么一起通过，要么都不通过，并拒绝整个修改？在第一次冲突之前，而不是之后，就决定哪些字段要作为一组一起传递。

每当我看到一个双向集成，我都会问：**当两边都修改同一份数据时会怎样？**如果答案是“那多半不会发生”，我们就还没做完。哪个胜出，我们是拒绝、排队、比较版本，还是审核？这个字段到底应该在两边都可以编辑吗？有时最好的双向设计，是对某个属性去掉一个方向：Salesforce 可以发起请求；只有 ERP 发布被接受的值。数据仍然双向流动，但只有一个系统主控这个字段。这个区别就是一切。

层级也是主数据

关系也可以是主数据。一个全球母公司，下面有北美和欧洲区域，每个区域下面有各国的子公司：层级本身就承载着含义。谁是母公司？哪个子公司属于哪个法人实体？哪些客户汇总到全球客户？这会驱动报表、区域、定价、合同、信用风险敞口、服务、数据访问和分析。一个层级可能和其中的记录一样重要，它需要同样的治理。（考试明确提到了层级管理；它很容易被忘记。）

在 Salesforce 上，客户层级是用上级客户字段构建的。Lightning 的层级视图最多显示 2,000 个客户，而且只显示用户有权看到的那些；层级中不支持个人客户；而客户地点用来区分一家公司的不同地点（Considerations for Using Account Hierarchy (opens in a new tab)，英文）。但上级客户字段并不能回答那个架构问题：谁拥有这个层级？

考点。掌握客户层级的基础知识：它是用上级客户构建的；Lightning 视图最多显示 2,000 个客户，而且只显示用户能看到的客户；不支持个人客户；客户地点用来区分一家公司的不同地点。

一个层级，好几个主控方

根据我的经验，**层级是分头主控的。**北美的实体来自 SAP，欧洲的来自另一个 ERP，新的潜在客户在 Salesforce 中构建，而一个被收购的子公司还没有迁移过来。谁拥有这个层级？**这取决于是哪个分支。**每个 ERP 控制自己的分支；Salesforce 控制潜在客户的关系，直到它们转换。这是一种合理的架构，只要每个人都知道边界在哪里。逐个分支地决定。

Click to enlarge

层级的权威可以逐个分支地分配。

所以不要让上级客户字段掩盖了权威。一个用户在 Salesforce 中给一个子公司重新指定了上级。技术上很简单。在架构上，他们是不是刚刚改变了公司的法律结构？如果 ERP 主控着那个分支，多半不是，所以 Salesforce 应该阻止它，或者把它变成一个变更请求。又或者 Salesforce 合理地保留着一个商业层级，而 ERP 保留着法律层级。那么也许它们根本就不应该是同一个关系。

一家公司可以有好几个合理的层级：法律层级、计费层级、销售层级、服务层级、地理层级。全球母公司签合同，各区域各自获得服务，计费通过一个共享的财务实体进行，销售按区域管理。哪个是真正的层级？全都是；它们回答的是不同的问题。错误在于假设必须只有一个。对每一种关系，都应该有清晰的权威：这是把模块 1 的属性原则运用到关系上。

而且并不是每一个父子关系都是主数据。把今天的配送归到一条路线上是一种关系，但它是交易性的，是一个运营事件。客户层级描述的是一种持久的业务关系。两者在模型中看起来都像父子关系；它们的生命周期却不同。要问这个关系意味着什么，以及这种含义会持续多久。

一个客户，两套 ERP

讲到这里时，我会问在场的人：谁合作过只有一个 Salesforce、却有不止一套 ERP 的客户？每次都有人举手。问为什么，就会发现这些 ERP 是按区域划分的（一套用于北美，一套用于欧洲），按职能划分的（一家水管公司收购了一家电气公司，双方各自保留自己的 ERP），或者只是历史原因：这项业务是收购来的，还没有人把它迁移过来。

以 Steve’s Plumbing 作为客户。它在北美开展业务，所以北美的 ERP 中有它的一条客户记录。后来它在慕尼黑开设了办事处，欧洲的 ERP 又为它创建了自己的一条客户记录，带着自己的客户编号。同一家公司，两条记录，两个 ID。我该如何在一个 Salesforce org 中表示它？我见过三种方式。

**客户层级。**Steve’s Plumbing 是上级，Steve’s Plumbing North America 和 Steve’s Plumbing Europe 是子客户，每个子客户代表一套 ERP 中的记录。问题在于：这些子客户其实已经不再是 Steve’s Plumbing 了。它们是在某个区域开展业务的 Steve’s Plumbing，而正如我们刚才看到的，层级是承载含义的。

**平级客户。**两个客户并排，各自带一个字段，说明它属于哪套 ERP：公司代码、区域。没有任何东西被隐藏。代价体现在报表上：要在全球范围内看到 Steve’s Plumbing，你需要某种东西来说明这两个客户是同一家公司。

**一个客户，每套 ERP 一个子记录。**一个 Steve’s Plumbing，再加一个子对象，每套 ERP 一条记录，保存该 ERP 的客户 ID。两套 ERP 也好，十套也好。销售人员看到的是一个客户，下的是一张订单；在幕后，由流程决定每个订单行发往哪套 ERP：电气工作发往电气 ERP，水管工作发往水管 ERP。但现在你必须决定，对于名称和地址这样的共享值，哪套 ERP 是主要的，以及当客户存在于一套 ERP 中而不在另一套中时会怎样。

Click to enlarge

一个客户，两套 ERP：在 Salesforce 中表示它的三种方式。

问他们如何让各套 ERP 保持同步

那么选哪一种？首先：**销售人员应该看到多少 ERP 结构？**如果他们一直都知道北美和欧洲是两项独立的业务，因为他们登录的是其中一套 ERP 或另一套，那就不要对他们隐藏这一点。把这种结构以平级客户的形式带进 Salesforce。如果业务方希望在销售面前只有一个 Steve’s Plumbing，那你考虑的就是一个客户、每套 ERP 一个子记录。

然后是真正起决定作用的问题，而它不是在 Salesforce 中决定的。我会问客户：**你们如何在各套 ERP 之间让这两条记录保持同步？**不是每套 ERP 本地的东西，比如余额；那是交易数据。我指的是主数据：法定名称、地址。如果他们有一个团队负责让两套 ERP 保持同步，我们就可以把它们合并成一个客户。如果他们在自己的 ERP 中都无法让它们保持同步，又怎么能指望我们在 Salesforce 中让它们保持同步？那就用平级客户，或者层级。

记住 ERP 是什么。这些是庞大的系统，需要数年才能落地，而且它们有自己管理主数据的方式。Salesforce 不会去驱动它们。我们控制不了 ERP。我们能控制的是如何在 Salesforce 中表示它们。

位于中间的 MDM

有些客户在我们到来之前就已经解决了这个问题。一家大公司，经营多年，有好几套 ERP：他们早在 Salesforce 之前就遇到了这个问题，并在中间放了一个专门的 MDM 产品，在各套 ERP 之间居中协调。这就是模块 2 中的共存式或集中式 MDM。现在 Salesforce 不再和每一套 ERP 分别对接。它指向一个地方，即 MDM 中心，并获得客户的单一表示。不过，别指望经常遇到这种情况。这些本身就是大型实施项目；这么多年来，我只参与过两三次。而且即使有了 MDM 中心，你可能仍然需要那个子对象，让每张订单知道它要发往哪套 ERP。

Click to enlarge

位于中间的 MDM：Salesforce 指向一个地方。

Steve Trucking：这是谁的层级？

一个零售合作伙伴有它自己的结构：公司总部、区域事业部、配送中心、门店。Steve Trucking 拥有这个层级吗？不；合作伙伴是它自己组织结构的权威。但 Steve Trucking 可能需要它自己对这些地点的商业视图，用于合同、客户管理、服务和报表，也许是在合作伙伴下面为每个配送中心建一个子客户。两个合理的层级，两个权威。给它们起名字，不要假装一棵树就能代表所有的关系。

让边界看得见

每当权威被拆分时，我都希望边界是可见的：字段命名、记录元数据、源系统标识符、权限、集成行为、文档。我不希望的是，一个开发人员要读完五个集成，才发现“这些上级客户的值来自 SAP，潜在客户除外，欧洲除外”。那不是一个可维护的权威模型。如果层级是分头主控的，就把这种拆分写下来。如果权威在转换时发生变化，就把这个变化写下来。如果 Salesforce 只能请求修改而不能直接修改，就让这一点在体验中一目了然。

在 Salesforce 中，这从一个字段开始。需要有一个字段明确说明这是主数据：ERP 的键，或者一个“是否为主数据”标志。用这个字段而不是记录类型来驱动字段的可编辑性；有了 Dynamic Forms，你不再需要记录类型来把 ERP 的字段显示为只读（第 5 章，每个数据流一个记录类型）。你可以允许在主控系统之外创建记录，但要盯住编辑。

考试之外：AI 改变了什么。一位客户告诉智能体：“把我们的账单地址改成 125 Main Street。”这个字段就在 Salesforce 里。智能体应该更新它吗？如果 ERP 拥有它，就不应该。智能体需要的是写入权威，而不只是字段访问权限：它的操作应该编码经批准的路径，即提交一个变更请求，并说“我已经提交了这项修改，正在处理中”，而不是谎称“我已经更新了您的账单地址”。

架构师在这里决定什么

• 在 Salesforce 中的一次编辑，是修改了权威数据，还是向拥有它的系统请求修改。
• 双向数据流如何区分发起的变更和回声，并处理拒绝、冲突、延迟和故障。
• 谁拥有每一个层级，必要时逐个分支地决定。
• 对于存在于好几套 ERP 中的同一个客户：用层级、平级客户，还是一个客户、每套 ERP 一个子记录，取决于客户让其各套 ERP 保持同步的能力。
• 相互竞争的层级是否其实是不同的合理关系：法律、计费、销售、服务。
• 如何让用户、集成、开发人员和智能体看到权威边界和经批准的写入路径。

共享的权威不是问题。模糊的权威才是。好几个 ERP 可以主控不同的分支，Salesforce 可以主控某些属性、请求修改另一些属性，好几个层级可以描述同一个企业。这一切都行得通，只要对每一个重要的属性和关系，你都能说出谁拥有它，谁可以修改它，权威的修改在哪里进行，以及系统之间不一致时会怎样。如果你说不出来，在图上再加一个双向箭头也解决不了问题。

延伸探索

• Salesforce Help，Considerations for Using Account Hierarchy (opens in a new tab)（英文），查阅日期 2026-10-14。