層級與雙向資料

🌐 另有 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。