所有權與生命週期

🌐 另有 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 翻譯，尚未經過社群審閱。 閱讀英文版

第 8 個模組，共 10 個，屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。 上一篇：關係會帶來後果 · 下一篇：保持資料一致

**本模組回答的問題：**誰擁有這條記錄，它在整個生命週期中會經歷什麼？

看一個資料模型時，我不只想知道有哪些物件以及它們如何連線。我想知道記錄隨著時間推移會經歷什麼。誰建立它們？誰擁有它們？誰可以重新分配它們？當業務關係變化、它們不再活躍時會怎樣？它們應該被刪除嗎，我們要保留多久？這些都不會出現在 ERD 上，也就是實體關係圖：第 2 章資料模型裡的那些方框和連線。但這些全都是資料架構。而在 Salesforce 上，所有權正是資料模型和安全模型迎頭相撞的地方。

所有權不只是欄位裡的一個名字

管理員在記錄上看到所有人，會把它當作一個標籤來讀：Bart 擁有這個客戶，Lisa 擁有那個案例。它可以是這個意思。但在 Salesforce 上，所有權也是一種平台機制。在有所有人的物件上，所有人決定了誰能通過角色階層、共用規則、佇列和重新分配看到這條記錄。所以當我問「誰擁有這條記錄？」時，我不是在問頁面上寫誰的名字。我是在問我們給它附加了什麼樣的安全和生命週期行為。所有人可以是一個使用者，對於某些物件（其中包括自訂物件、案例和潛在客戶）也可以是一個佇列，無論哪種，所有人都對這條記錄擁有完全存取權限（Understanding Sharing (opens in a new tab)，英文）。

這就是為什麼我把業務責任和記錄所有權分開。有時它們是同一個人，有時不是。如果業務說一位排程員對一次配送負責，這並不自動讓排程員成為所有人。責任可以放在它自己的欄位裡，而所有權則設定成能支撐安全和規模的樣子。不要只因為兩者都用了「所有者」這個詞就把它們混為一談。

共用表：所有權在這裡變成存取權限

有些人甚至不知道共用表是什麼。每個資料架構師都應該知道。

一條記錄的大部分共用資訊都儲存在一個相關的共用物件裡，這是 Salesforce 版本的存取控制清單（Understanding Sharing (opens in a new tab)，英文）。Account 有 AccountShare，Contact 有 ContactShare，自訂物件也有自己的共用物件：Truck__c 有 Truck__Share（Sharing a Record Using Apex (opens in a new tab)，英文）。其中每一行說明四件事：

• 哪條記錄：父記錄 ID。
• 誰：一個使用者，或者一個組（公用組、某個角色的組、一個區域）。
• 多少權限：讀取、編輯，或者全部（完全存取）。
• 為什麼：行原因（Row Cause）。所有人對應 Owner，共用規則對應 Rule，手動共用對應 Manual，還有 Team、Salesforce 在客戶與其子記錄之間新增的隱式原因，以及開發人員為 Apex 共用定義的原因。

在課上，我一邊共用一條記錄，一邊開啟 Workbench 查詢共用表，你會看著行出現又消失。當有人問「為什麼這個人能看到那個？」時，答案往往就躺在某一行裡，連同它的原因。

但並不是所有東西都在裡面。組織範圍預設設定不是一行。角色階層也不儲存在那裡：所有人上級那些人的存取權限是在需要時才計算出來的。而「檢視所有」、「修改所有」、「檢視所有資料」和「修改所有資料」則完全跳過共用表（Sharing a Record Using Apex (opens in a new tab)，英文）。正如我在課上說的：勾選「檢視所有」，你就繞過了共用表。

Salesforce 還會因為記錄之間的關聯而替你共用一些記錄。這就是隱式共用，它作用於客戶與其子記錄之間。如果你能看到一個連絡人、案例或商機，你也能讀取它所屬的客戶。而客戶所有人可以存取該客戶的連絡人、案例和商機，存取級別由所有人的角色設定（Implicit Sharing (opens in a new tab)，英文）。在最近的版本中，Salesforce 會在需要時才計算其中一部分子記錄存取權限，而不是把它儲存為行，所以查詢共用表時看不到它，也不必驚訝。這裡我只給你一個提示；細節在 Relationships and Built-In Sharing（英文）裡。

還有一個例外，適用於你有大量外部使用者的情況。高容量社群使用者，也就是為成千上萬乃至數百萬客戶設計的 Customer Community 許可證，沒有角色，不能加入公用組，也不能通過共用規則或手動共用獲得記錄（About High-Volume Community or Site Users (opens in a new tab)；Sharing Rule Considerations (opens in a new tab)，英文）。對他們來說，共用表不是答案：他們通過共用集存取記錄，共用集把一條記錄的客戶或連絡人與使用者自己的客戶或連絡人相比對。這正是這些許可證能夠擴充套件的原因之一。Sharing and Visibility 課程在 Sharing with External Users（英文）裡講到它。

還要記住模組 7：從物件根本沒有共用物件。它的存取權限來自主物件的共用物件，以及主要-詳細資料關係欄位上的共用設定。

資料架構師為什麼要關心？因為所有權就寫在這張表裡。每一次更換所有人，每一條新的共用規則，每一個使用者在角色或組之間的移動，都意味著 Salesforce 要新增和刪除行。幾千條記錄時沒人會注意到。到了一千萬條，而且大部分歸一個使用者所有時，就是我們馬上要遇到的重新計算。

考點。自訂物件的共用物件命名為 Object__Share，比如 Truck__Share。從物件沒有共用物件：它的存取權限來自主物件。而當一條記錄的所有人發生變化時，它的手動共用會被刪除，而帶有開發人員自訂原因的 Apex 共用會保留下來。

資料模型在這裡把接力棒交給安全模型，其餘的我在 Sharing and Visibility Architect 課程中講：Steve’s 22 Ways to Share a Record（英文）、Org-Wide Defaults, Ownership, Queues and the Role Hierarchy（英文）、講隱式共用的 Relationships and Built-In Sharing（英文），以及講 Apex 共用原因的 Programmatic Sharing and Secure Code（英文）。在本課程中，第 12 章會針對人、應用程式和代理程式把這些串起來。

有時所有權是繼承來的

在上一個模組裡我們看到，主要-詳細資料關係中的子記錄沒有自己的所有人；它跟隨父記錄。這往往完全正確。業務需要給一次配送上的每個項目各設一個不同的所有人嗎？不需要。配送擁有生命週期，項目屬於它。這就是為什麼關係設計和所有權設計要一起做：當你選擇了主要-詳細資料關係時，你就已經做出了所有權決定的一部分。

系統建立的記錄歸誰所有？

事情從這裡開始變得有趣。一個人建立了一個客戶，也許他就成了所有人。但一個 ERP 一夜之間發來了 10 萬筆交易。它們歸誰所有？整合使用者？一個佇列？根據資料推算出的區域所有人？一個五年沒人想起過的系統帳戶？而現在代理程式也會建立記錄。

我的立場是：**這取決於所有權對共用是否重要。**整合使用者或代理程式使用者是一個有效的使用者，它可以擁有記錄。如果在這個物件中，所有權決定存取權限（通過角色階層或共用規則），就把記錄分配給合適的所有人：一個真實的使用者、一個佇列，或者一個專門的所有人使用者。如果不決定存取權限，保留系統使用者作為所有人可能是更好的選擇，因為這樣稽核軌跡就能直接追溯到建立這條記錄的東西。

不管怎樣，都要有意識地決定。一個擁有所有東西的整合帳戶，已經悄悄地成了你安全架構的一部分，總得有人知道它一旦被停用會發生什麼。

所有權可能變成規模問題

分佈也很重要。一千萬條記錄分散在幾千個所有人名下是一種形狀。一千萬條記錄歸一個使用者所有，則是截然不同的另一種。當單個使用者擁有某個物件超過 10,000 條記錄時，Salesforce 把它叫作所有權資料傾斜（Ownership Data Skew (opens in a new tab)，英文）。它通常發生在有人把所有東西都停放在一個使用者或佇列上時：所有未分配的潛在客戶都放在一個佔位使用者名稱下，每條整合記錄都歸整合使用者所有。在那個使用者在角色階層中移動，或者進出某個共用規則所依賴的組之前，它都是無害的。然後 Salesforce 就得調整海量的共用條目，你會遇到長時間執行的重新計算。

相關建議很實用。在可能的情況下，把所有權分散到更多使用者身上。如果一個使用者必須擁有大量記錄，就讓他不在角色階層中；如果他需要一個角色，就把他放在頂部一個單獨的角色裡，並且不要移動他，同時讓他不進入共用規則所用的公用組（Ownership Data Skew (opens in a new tab)，英文）。同樣的思路也適用於上一個模組裡那個子記錄太多的父記錄，即父子資料傾斜。

所以分佈是物理模型的一部分。不要只問有多少條記錄；要問它們是如何分佈的。這是「零的個數」的另一個版本：不只是有幾個零，還有零集中在哪裡。第 2 部分會深入討論資料傾斜；在這裡，我希望你能預見它的到來。Sharing and Visibility 課程會在 Sharing at Scale（英文）中再次討論它。

「預設所有人」變成了架構

有一個模式我總能看到。沒人知道某樣東西該歸誰所有，於是有人說：「全都分配給整合使用者吧」，或者「建一個叫 System 的通用使用者」。也許這是對的。但不要在無意中這樣做。一個臨時的預設值有變成永久的習慣：兩年後，每條記錄都屬於 integration@company.com，沒人記得為什麼，而改變它成了一個專案。這就是第 1 章的可逆性測試：在把一百萬條記錄交給一個所有人之前，問一問以後要改變它需要付出什麼。

重新分配是一個生命週期事件

所有人會變。銷售代表離職，區域調整，團隊重組，地區重新劃分。有什麼依賴於所有人：共用、自動化、報表、佇列、升級、整合？如果更換所有人會改變誰能看到這條記錄，那麼重新分配就不是管理員的清理工作。**它是一個安全事件，**而在一百萬條記錄的規模下，它也是一個運維事件。發生時留意共用表：所有人變化時，手動共用會被刪除，而帶有開發人員自訂原因的 Apex 共用會在變化後保留下來（Understanding Sharing (opens in a new tab)，英文）。在課上，我把一條記錄共用給某人，然後更換所有人，那個人就失去了存取權限。全場每次都很驚訝。

還要記住，所有權不等於存取權限。所有人並不是唯一需要看到一條記錄的人，而 Salesforce 有很多授予存取權限的方式：角色階層、共用規則、團隊、區域、手動共用和程式化共用。Sharing and Visibility 課程會深入討論這些，從 Steve’s 22 Ways to Share a Record（英文）開始。架構師的要點更簡單：**不要用所有權來解決每一個存取問題。**如果你只是為了讓某人能看到一條記錄而在調換所有人，你多半是在解決錯誤的問題。

建立只是開始

很多資料建模止步於建立：欄位、物件、關係，完事。但這條記錄可能會存在十年。它會被更新，更換所有人，改變狀態和關係，變為不活躍，成為歷史，可能需要歸檔，有一天也許還要被刪除。架構不只是記錄如何誕生，而是從誕生到消亡之間發生的一切。

Click to enlarge

不要只因為東西舊了就刪除

一個零售合作夥伴不再派活了。刪除這個客戶？不會自動刪除：它的配送、索賠和計費歷史仍然重要。一輛卡車退役了。把它連同它的配送歷史和貨損索賠一起刪除？這樣東西也許不再活躍，但它的資料仍然有用。所以我把不活躍和消失分開。一輛退役的卡車可以留在模型裡；一位前員工仍然可以出現在稽核歷史中。架構必須在運營關係結束之後，保留那些重要的事實。

保留是一項業務需求

另一面是：永遠保留所有東西也不是架構。儲存會增長，報表會變慢，搜尋會更嘈雜，而隱私法可能規定有些資料必須刪除。所以我想要一個明確的答案：這個我們要保留多久？「Salesforce 會保留它」不是保留策略。

而這主要是一個關於交易資料的問題。參考資料，比如產品、服務類型、配送中心，不會變得很龐大，而且有其他記錄指向它，所以它通常會留下來。客戶資料介於兩者之間：也許有一天你會讓一個客戶退役，尤其是當你持有個人資料而保留它的理由已不復存在時。但資料量在交易裡：配送、訂單、案例、預約，每天都在建立，永無止境。那才是會增長到幾億行的東西，也正是保留必須明確的地方：也許運營資料在 org 裡保留兩年，財務記錄在某個地方保留七年，某些照片保留九十天。這些都是業務規則，如果沒人問過，架構師就應該去問。

我在課上說了很多年：如果你今天不歸檔，你還會有歸檔的那一天嗎？「以後再說」往往會在三億條記錄時變成一個緊急專案。第 2 部分有一整個模組講歸檔和清除，就建立在同一個問題之上。

Steve Trucking：一次配送歸誰所有？

一次配送由整合根據零售合作夥伴的裝貨清單建立，每天大約 3,300 次。它歸誰所有？不是零售合作夥伴；那是一個業務關係。不是收貨人。配送小組執行它，但每次配送小組換卡車時，記錄都應該更換所有人嗎？排程員？配送中心？一個佇列？建立它的整合使用者？

現在運用本模組，從決定它的那個問題開始：**所有權是否決定了某人對配送的存取權限？**在 Steve Trucking，答案是否定的。排程員看到的是他們配送中心的配送，配送小組看到的是他們路線上的配送，每個零售商在合作夥伴入口網站中看到自己的配送。這些都不取決於誰擁有這條記錄；它們來自配送中心、路線和合作夥伴。

所以我的答案是：**整合使用者擁有這些配送。**這是一個系統使用者有意擁有記錄的好例子：

• **稽核軌跡是誠實的。**每次配送的所有人都說明了它的來源：裝貨清單整合。
• **存取權限來自共用，而不是所有權。**基於配送中心的條件共用規則讓每個配送中心的團隊看到自己的配送；合作夥伴通過入口網站存取他們的配送。
• 傾斜已在設計中化解。每天 3,300 次，整合使用者三天就會擁有超過 10,000 次配送，所以從第一天起就是所有權資料傾斜，只要我們提前規劃，這就沒問題。整合使用者沒有角色，所以層級中它上方沒有任何東西需要重新計算，而且它不加入我們共用規則所用的公用組。
• **沒人重新分配配送。**配送小組換卡車，排程員換班，而所有人從不改變，所以不會有重新分配風暴，也沒有會丟失的手動共用。

還要寫下如果這個使用者哪天被停用或被替換會發生什麼，因為它現在擁有幾百萬條記錄。這正是下一個團隊需要找到的那個決定。

**考試之外：AI 改變了什麼。**代理程式以機器的速度建立和修改記錄。如果一個代理程式以它自己的使用者身分建立了 10 萬條記錄，「以後再改所有人」就會變成資料傾斜、共用重新計算和一個清理專案。在代理程式上線之前就決定它的所有權規則，用的是同一個問題：在這裡，所有權對共用重要嗎？

架構師在這裡決定什麼

• 所有權代表的是業務責任、安全機制，還是兩者兼有，以及如果責任不放在所有人欄位裡，它放在哪裡。
• 記錄需要自己的所有人，還是應該從父記錄繼承。
• 整合和代理程式建立的記錄歸誰所有，取決於所有權是否決定共用。
• 所有權如何分佈，以及當一個使用者必須擁有大量記錄時如何避免所有權資料傾斜。
• 記錄何時變為不活躍，何時歸檔，保留多久，以及何時刪除才是正確的。

看一個物理模型時，不要只問資料存放在哪裡。要問**今天誰擁有它，明天誰可能擁有它，以及當我們不再需要它時會怎樣。**接下來：即使有了正確的物件、欄位、關係和所有人，資料仍然必須保持可信。

延伸探索

• Apex Developer Guide，Understanding Sharing (opens in a new tab)（英文），查閱日期 2026-10-13：所有人（一個使用者，或者對於自訂物件、案例和潛在客戶來說，一個佇列）擁有完全存取權限；大部分共用存放在一個相關的共用物件裡；角色階層在執行時推導；所有人變化時手動共用會被刪除，Apex 託管共用會保留；行原因的取值。
• Apex Developer Guide，Sharing a Record Using Apex (opens in a new tab)（英文），查閱日期 2026-10-13：AccountShare、MyCustomObject__Share；從物件沒有共用物件；共用物件不記錄的內容（組織範圍預設設定、角色階層、「檢視所有」和「修改所有」）。
• Salesforce Help，Implicit Sharing (opens in a new tab)（英文），查閱日期 2026-10-13：客戶與其連絡人、案例和商機之間的存取權限。
• Salesforce Help，About High-Volume Community or Site Users (opens in a new tab) 和 Sharing Rule Considerations (opens in a new tab)（英文），查閱日期 2026-10-13：沒有角色，沒有共用規則或手動共用；改用共用集。
• Sharing and Visibility Architect 課程：Steve’s 22 Ways to Share a Record、Org-Wide Defaults, Ownership, Queues and the Role Hierarchy、Relationships and Built-In Sharing、Programmatic Sharing and Secure Code、Sharing with External Users、Sharing at Scale（英文）。
• Salesforce Developers，Designing Record Access for Enterprise Scale，Ownership Data Skew (opens in a new tab) 和 Parent-Child Data Skew (opens in a new tab)（英文），查閱日期 2026-10-02。