選擇合適的物件
另有 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)
第 5 個模組，共 10 個，屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。 上一篇：這些資料放在哪裡？ · 下一篇：欄位也是架構
**本模組回答的問題：**這個業務概念應該成為哪種 Salesforce 物件，許可又允許什麼？
在 Salesforce 裡，最容易做的事情之一就是建立一個自訂物件。正因如此，我認為我們建立的自訂物件太多了。
你在一次需求會議上，有人說：「我們需要追蹤我們的經銷商。」新建自訂物件：Distributor。搞定。可是我希望架構師先問另一個問題：**經銷商是什麼？**它是一家公司。Salesforce 已經有一種相當不錯的方式來表示公司，它叫客戶（Account）。這並不意味著答案總是客戶。但如果我必須解釋為什麼一家公司不是客戶，我希望有一個比「業務方管它們叫經銷商」更好的理由。
這是第 2 章的邏輯模型與平台相遇的地方，而我的出發點很簡單：如果業務概念與某個標準物件的本來用途乾淨契合，就從那裡開始。
從含義開始
Section titled “從含義開始 ”即使某樣東西值得成為一個物件，它也不會自動值得成為一個自訂物件。問一問這樣東西實際上代表什麼。任何形式的企業或組織？從客戶開始。與這個組織打交道的一個人？連絡人。客戶擁有或購買的某樣東西？資產。你想賣出去的某樣東西？那麼商機就該進入討論了。
這就是為什麼我們在模組 2裡先看向母艦。那些模型並不適合每一個業務，但我們不應該因為自建一個感覺更乾淨就忽視它們。在點選 New Custom Object（新建自訂物件）之前，先問一問：Salesforce 是如何為這個概念建模的，圍繞那個模型已經構建了什麼，如果替換它，你會放棄什麼。
乾淨契合測試
Section titled “乾淨契合測試 ”我的測試只有一個問題：**這個業務概念是否與這個標準物件的本來用途乾淨契合？**如果是，我就傾向於用標準物件。
經銷商是一家與我們有業務關係的公司，所以客戶是乾淨契合的。我不介意使用者把一家公司叫經銷商，另一家叫供應商，再一家叫零售合作夥伴，還有一家叫客戶。這些是業務角色，它們不需要四個物理物件。**不同的業務名稱並不自動意味著不同的資料結構。**一個類型、一個記錄類型或一個關係就可以承載這種差別。
這個測試反過來也適用。在第 1 章裡，我給你留了一個問題：一個客戶的業務有很多個配送地點。每個地點應該是一個客戶（Account），還是一個自訂物件？
客戶能給你很多東西。你會得到地址欄位，以及所有已經預期使用客戶地址的東西：報表、地圖、整合。但你也會得到它的開銷：大量欄位、共用、層級、所有權，掛在客戶身上的一切，而其中大部分都和一個單獨的地址無關。僅僅為了一個備用地址，你就要背上一大堆用不上的重東西。
而一個自訂物件，作為客戶的子物件，可以很輕量：只有地址欄位，代表一個我們要送貨的地方，有它自己的生命週期，我可以獨立地控制它。
所以這是一種平衡：**你承擔的分量，對比你得到的價值。**如果我需要的只是一個有自己生命週期的地址，那我就會用自訂物件。
案例下面的子問題也是一樣。如果每個子問題真的就是一個案例，由坐席處理，有自己的狀態和服務級別，那就用模組 2裡的上級案例（Parent Case）把它們巢狀起來。但如果它只是一個沒人會當作案例來處理的檢查清單條目，一個完整的案例就會帶著很多永遠用不上的東西，而一個簡單的自訂子物件可能更輕。不是因為自訂更乾淨，而是因為含義不同，或者分量不對。
標準物件自帶包袱
Section titled “標準物件自帶包袱 ”當你選擇一個標準物件時，你選擇的不只是它的欄位。你選擇的是 Salesforce 的各個產品已經理解的東西：報表、自動化、內建關係、產品功能、AppExchange 軟體包，以及 Salesforce 接下來要構建的任何東西。這可能有巨大的價值。
標準物件也帶著自己的主張：既有的行為、關係、安全方面的考慮，有時還有許可要求，以及你用不上的功能。所以「永遠用標準物件」不是我的規則。我沒有「永遠」的規則。我有的是一種傾向：**當含義乾淨契合，並且圍繞它的平台行為是在幫助設計而不是與之作對時，就用標準物件。**如果我花五年時間，讓商機去表現得像一個並不是銷售機會的東西，那麼堅持用標準物件並沒有給我帶來任何好處。我只是在另一個方向上做了錯誤的妥協。
資產是個好例子
Section titled “資產是個好例子 ”資產是人們常常忽略的標準物件之一。我能給出的最簡單的說法是：**它是客戶擁有的一樣東西。**也許是從我們這裡買的，也許不是。我仍然在意放在客戶現場的競爭對手的產品，因為我在維修它，或者想替換它，或者需要了解他們的裝機情況。如果我沒有先看看資產就建立了 Customer_Product__c，我就跳過了一個架構問題。資產不會自動勝出，但它值得被評估。
個人帳戶：這個人什麼時候就是客戶？
Section titled “個人帳戶：這個人什麼時候就是客戶？ ”在模組 2裡，我們認識了個人帳戶：把客戶和連絡人合在一條記錄裡，用於身為個人的顧客。現在來做決定。
我的立場是：**對於 B2C，很難不用它們。客戶和連絡人開箱即帶的東西實在太多，所以付出的成本和開銷是值得的。而成本確實存在：儲存大約是企業客戶的兩倍，一個開啟後就關不掉的開關，而且有些外部許可不能使用它們。Partner Community 不能與個人帳戶一起使用（Experience Cloud User Licenses (opens in a new tab)，英文）。所以問題不是「我們的資料庫裡有沒有人？」每個 org 裡都有人。問題是「在這個業務裡，這個人真的就是客戶嗎？」**連絡人是一個人，並不會讓它成為個人帳戶。決定這一點的是業務關係。
現在讓我把一切都複雜化：許可
Section titled “現在讓我把一切都複雜化：許可 ”到目前為止：找到概念，尋找最乾淨契合的標準物件，含義不契合時用自訂物件。現在是架構師的追問：**誰需要使用它？**你可以設計出一個漂亮的模型，然後發現需要這些資料的人裡有一半沒有你所選物件的許可。許可是資料模型的一部分。
三種內部許可
Section titled “三種內部許可 ”先從你自己的員工說起。在公司內部，有三種許可類型我希望每位架構師都爛熟於心，因為它們決定了每個使用者能看到什麼、能做什麼，也就決定了你的資料模型可以依賴什麼。
Sales Cloud（現在叫 Agentforce Sales）。這些使用者擁有完整的 Salesforce 使用者許可：標準 CRM 物件，以及任何標準或自訂應用。也就是在客戶和連絡人之上，還有潛在客戶、商機和預測，甚至還有案例：銷售代表可以在打電話之前看到客戶未結的案例。建立和執行市場活動還需要再加一樣東西：Marketing User 功能許可。
Service Cloud（現在叫 Agentforce Service）。同樣是 Salesforce 使用者許可，只是為服務而配置。案例處於中心，在 Service Console 中處理：Service Cloud User 功能許可正是開啟 Salesforce Console for Service 的那把鑰匙。服務級別協議就在這裡，通過權利（Entitlement）管理和里程碑來實現；Knowledge 也在這裡登場，大多數版本要把它作為附加功能單獨購買。
Platform（Salesforce Platform）。面向需要你的自訂應用、而不需要 CRM 的人。他們能使用客戶、連絡人、報表、儀表板、文件，以及 org 裡的每一個自訂應用。他們用不了的是：預測、潛在客戶、市場活動和商機。它更便宜，這正是那麼多大型自訂應用都執行在它上面的原因，也正是它可能讓你的資料模型栽跟頭的原因。
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| 使用者許可 | Salesforce | Salesforce | Salesforce Platform |
| 用途 | 銷售 | 支援客戶 | 自訂應用 |
| 客戶、連絡人 | 是 | 是 | 是 |
| 潛在客戶、商機、預測 | 是 | 是 | 否 |
| 案例 | 是，用於檢視客戶的案例 | 處於中心，在 Service Console 中 | 否 |
| 服務級別協議 | 否 | 是，權利和里程碑 | 否 |
| 自訂物件和應用 | 是 | 是 | 是 |
像架構師那樣讀這張表。如果有一大批使用者用的是 Platform，那麼任何把他們的工作放到商機上的設計，還沒開始就已經壞了。如果高管需要 SLA 數字，他們所用的許可決定了他們能不能看到。這三種類型決定了行為。
當許可決定物件時
Section titled “當許可決定物件時 ”商機是我遇到最多的受害者。你在表裡已經看到了：Platform 使用者用不了它（Standard User Licenses (opens in a new tab)，英文），Customer Community 使用者也不能使用它。於是需求看起來像商機，有人說「我們用商機吧」，然後我問誰需要存取。如果有一大批人用的是 Platform 或 Customer Community 許可，許可就不再是一個採購細節，而是一個架構約束，它通常會把設計推向自訂物件。
往上也是一樣。我在課上會問：CEO 想要漂亮的儀表板，用 Sales 許可還是 Service 許可？Sales 使用者可以看到銷售物件，甚至案例，所以對於銷售儀表板和未結案例數量，Sales 就夠了。但一旦高管想要 SLA KPI（一個案例還有多久會違反服務級別），這些資料就在權利和里程碑裡，而權利管理需要 Agentforce Service，也就是以前的 Service Cloud（Supported Editions for Service Features (opens in a new tab)，英文）。現在你就得升級高管們的許可了。傾聽業務需求，並知道它所需的資料底下是哪種許可。
我把許可想像成體育場裡的座位。大家看的是同一場比賽。如果我買了中間的貴座，我能近距離看到兩支球隊。如果我坐在角落的看臺上，座位沒有軟墊，我得拿著望遠鏡看。
這就是外部許可，面向公司之外的人：登入 Experience Cloud 站點的客戶和合作夥伴。有三種我希望你瞭解。
Customer Community：露天看臺。為需要案例和知識庫的大量外部使用者而設計：比如一位檢視自己支援案例進度的客戶。座位價格大約是一半，可以發給數量龐大的使用者。坐在上面你會失去什麼？報表、儀表板，以及共用表：更高等級才有的基於角色的共用。它可以與個人帳戶一起使用。
Customer Community Plus：往下坐到大約一半的位置。Salesforce 把它描述為面向需要報表、儀表板和標準共用的外部使用者的許可：比如一位要管理其他人存取權限、或者需要看到自己資料的客戶。
Partner Community：坐得更近，面向企業對企業，可以存取銷售資料。合作夥伴要跟進潛在客戶和商機：他們登記商機，並和你一起開展市場活動。這是能觸及銷售物件的那種外部座位。有一個問題：它不能與個人帳戶一起使用（Experience Cloud User Licenses (opens in a new tab)，英文）。
錯誤在於按照每個人都有貴票來設計，然後在實施時發現，你的大多數使用者都進不了你放他們資料的那個區域。這時你有三個選擇：買不同的座位，把體驗挪個地方，或者重新設計模型。三者都是架構。
付費方式會改變設計
Section titled “付費方式會改變設計 ”還有一個人們會忘記的問題：**這些使用者會如何登入？**外部許可有兩種形式。按成員計費：按使用者付費，適合每天都登入的 500 個合作夥伴。按登入計費：每月購買一定數量的登入次數，適合一年只登入幾次的五百萬客戶。同一天內多次登入仍然只算一次登入（Experience Cloud User Licenses (opens in a new tab)，英文）。
所以當有人說「我們要建一個客戶入口網站」時，我接下來的問題不是用哪個模板，而是：客戶是誰，有多少，多久來一次，他們需要什麼資料，他們被允許用這些資料做什麼？
當許可塑造模型時
Section titled “當許可塑造模型時 ”有時許可不只是決定用哪個物件；它會讓整個模型變形。有些平台許可把使用者限制在一個自訂應用裡，最多十個自訂物件（例如 Lightning Platform – One App；Standard User Licenses (opens in a new tab)，英文）。
在早年的一個專案裡，客戶是一家大型專業服務和建築公司，我們要為全體員工構建一個類似 LinkedIn 的東西：每個人的職位、技能、憑證、語言和專案，這樣他們就能找到在某個國家持證的橋梁建造者。如果沒有限制，我會建使用者職位、使用者技能、使用者憑證、使用者語言和使用者專案物件，再加上憑證和專案的參考清單。在十個物件的許可下，而且被告知不要把它們全用光，這就不可能了。於是它變成了一場猜歌名遊戲：我最少用幾個物件能把它建出來？答案是兩個。一個參考物件，每種清單（職位、技能、憑證、語言、專案）各有一個記錄類型；再加一個使用者屬性物件，帶著對應的記錄類型，指向它。
這不是最優的模型。做報表很痛苦，我也更希望它乾淨一些。但許可只允許這樣。我把這類物件叫作瑞士軍刀物件：把這個模式放在口袋裡備用，當限制讓你毫無餘地時，就打破玻璃，改用記錄類型來區分。只是要知道你在交換什麼。每個記錄類型需要不同的權限，可能最後還是會逼你把物件拆開。
使用者不再只是人
Section titled “使用者不再只是人 ”還有一個許可問題變得很重要：那些不是人的東西怎麼辦？整合有身分。代理程式有身分。Salesforce 現在有一種用於系統間整合的 Salesforce Integration 許可：只能用 API，不供人使用，每個 Enterprise、Unlimited 和 Performance Edition 的 org 都包含五個（Standard User Licenses (opens in a new tab)，英文）。所以不要只問哪些使用者需要存取。要問哪些身分需要存取：一個人、一個客戶、一個合作夥伴、一個整合、一個代理程式。然後再問每一個需要看到什麼、做什麼。
**考試之外：AI 改變了什麼。**隨著代理程式成為資料的又一個消費者和建立者，物件選擇和許可就不再只關乎人看的介面。要知道代理程式以哪個身分執行，這個身分能觸及什麼，以及模型是否把它需要的資料放在了它無法使用的物件或權限後面。
Steve Trucking：一個簡單的，一個難的
Section titled “Steve Trucking：一個簡單的，一個難的 ”Steve Trucking 與零售合作夥伴合作。零售合作夥伴是什麼？一個企業。簡單：客戶（Account）。我不會因為有人用了「合作夥伴」這個詞就建立 Retail_Partner__c。
再看收貨人，也就是接收冰箱的那個人。連絡人？個人帳戶？還是別的什麼？每年一百萬位新收貨人，而他們是零售合作夥伴的客戶，不是我們的。在理解關係、存取和規模之前，我正是不想貿然選定物件的那類問題。我們會在第 1 部分的檢查點上做出決定。
架構師在這裡決定什麼
Section titled “架構師在這裡決定什麼 ”- 一個業務概念是與某個標準物件的本來用途乾淨契合，還是它的含義或分量有所不同。
- 不同的業務標籤是不同的實體，還是同一個實體的不同角色。
- 在計劃的許可下，每一個需要這些資料的人、外部使用者、整合和代理程式，是否都能存取所選的物件。
- 使用者數量和登入模式（按成員計費還是按登入計費）如何塑造許可和模型。
- 什麼時候一個許可限制足以證明一個不那麼理想的模型是合理的，以及這種交換在報表和權限上要付出什麼代價。
重點不是標準物件好、自訂物件壞。重點是這個選擇有後果，而且有時決定它的根本不是那個名詞，而是需要使用它的人，以及機器。
- Salesforce Help，Standard User Licenses (opens in a new tab)（英文），查閱日期 2026-10-02，再次查閱 2026-10-12：Platform 使用者無權使用預測、潛在客戶、市場活動和商機；一個最多包含 10 個自訂物件的自訂應用；每個 Enterprise Edition 的 org 包含五個 Salesforce Integration 許可。
- Salesforce Help，Experience Cloud User Licenses (opens in a new tab)（英文），查閱日期 2026-10-02，再次查閱 2026-10-12：Partner Community 不能與個人帳戶一起使用；Customer Community Plus 用於報表、儀表板和標準共用；同一天內多次登入只算一次。
- Salesforce Help，Supported Editions for Service Features (opens in a new tab)（英文），查閱日期 2026-10-02，再次查閱 2026-10-12：服務級別協議（權利管理）隨 Agentforce Service 提供；在大多數版本中，Knowledge 需要額外付費。
- Salesforce Help，Available Feature Licenses (opens in a new tab)（英文），查閱日期 2026-10-12：Service Cloud User，「Access the Salesforce Console for Service」（存取 Salesforce Console for Service）；Marketing User 用於建立和管理市場活動。