Skip to content

標準資料模型

另有 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)

An aisle of a builders' supply warehouse, its racks stacked with ready-made standard doors, windows and stair parts, a cart waiting in the aisle.
圖片由 AI 生成

第 2 個模組,共 10 個,屬於 Data Architect 課程第 3 章Salesforce 資料架構。每個模組都可以單獨閱讀。 上一篇:Salesforce 資料平台:不只是資料庫 · 下一篇:自己動手:自訂物件

**本模組回答的問題:**Salesforce 已經為你建模了什麼,它又是怎麼組合在一起的?

在模組 1 裡我告訴過你要看向母艦:在發明某樣東西之前,先看看 Salesforce 自己是怎麼做的。這個模組就是我們真正去看的地方。Salesforce 已經在它的標準物件裡為你建模了大量業務,而在我走進的大多數 org 裡,其中有兩個模型承擔了大部分工作:Sales 模型和 Service 模型。在你能決定某樣東西是否值得一個自訂物件之前,你需要知道已經有什麼。這就是接下來兩個模組的內容。

是什麼讓一個物件成為標準物件

Section titled “是什麼讓一個物件成為標準物件 ”

標準物件是開箱即用的。它由 Salesforce 構建,有明確的用途,並帶有自己的欄位和關係。你可以給它加欄位,圍繞它做自動化,修改它的佈局,但你不能重新設計它:標準欄位和標準關係屬於 Salesforce。

看看這些名稱。Account、Contact、Case。**沒有字首,也沒有後綴。**這是 Salesforce 為自己保留的空間。我們構建的一切都以 __c 結尾,所以 Salesforce 可以隨時新增新的標準物件,永遠不會和你 org 裡的任何東西衝突。而它確實這樣做,每個版本都會。

在發展過程中的某個時候,有人構建了一個沒成功的產品物件,只好把它留在身後。這就是為什麼 API 名稱是 Product2。有人告訴我他們瞭解 Salesforce 時,這是我的第一道試金石。

從左邊開始,是潛在客戶(Lead):一個可能成為客戶的人。潛在客戶其實還不算模型的一部分。它是一個暫存區。當你轉換它時,Salesforce 會建立真正的記錄:一個客戶、一個連絡人,如果有一筆交易,還有一個商機。這就是為什麼我把潛在客戶畫在一邊。

客戶是公司。它的連絡人是公司裡的人。商機是和這個客戶的一筆交易。到這裡,沒有什麼出乎你的意料。

接下來就有意思了。交易裡有什麼?每一行都是一個商機產品,而商機產品並不直接指向產品。它指向一個價格手冊條目:這個產品,以這個價格,在這本價格手冊裡。價格手冊條目位於產品和價格手冊之間,所以同一個產品可以在標準價格手冊裡是一個價格,在你的合作夥伴價格手冊裡是另一個價格。

這是兩個先後變成了事物的關係。還記得第 2 章裡位於配送和產品之間的配送項目,以及位於狗和技能之間的狗狗技能(Dog Trick)嗎?Salesforce 在這裡做了完全一樣的事,而且做了兩次:商機產品位於商機和價格手冊條目之間,價格手冊條目位於產品和價格手冊之間。當你能讀懂這一點,你就能讀懂標準資料模型的大部分內容。

Sales 模型 Sales 模型。潛在客戶位於左側,轉換為客戶。一個客戶有多個連絡人和商機。一個商機使用一本價格手冊,並包含多個商機產品。每個商機產品由一個價格手冊條目定價。價格手冊列出多個價格手冊條目,產品則出現在多個價格手冊條目中,所以每個價格手冊條目連接一個產品和一本價格手冊。 轉換為 有 有 使用 包含 由…定價 列出 出現在 潛在客戶 客戶 連絡人 商機 價格手冊 商機產品 價格手冊條目 產品 恰好一個 零個或一個 一個或多個 零個或多個 © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

下面近距離看看這條鏈,以及把它連在一起的欄位:

近看定價鏈 以詳細資料模型呈現的定價鏈。商機產品帶有它的商機 ID、它的價格手冊條目 ID、數量和銷售價格,並由一個價格手冊條目定價。價格手冊條目帶有它的價格手冊 ID、它的產品 ID、標價,以及一個「使用標準價格」旗標。價格手冊有名稱和一個「是否為標準」旗標;產品有名稱和產品代碼。 由…定價 列出 出現在 價格手冊 價格手冊 ID 記錄 ID 名稱 是否為標準 商機產品 商機產品 ID 記錄 ID 商機 ID 價格手冊條目 ID 數量 銷售價格 價格手冊條目 價格手冊條目 ID 記錄 ID 價格手冊 ID 產品 ID 標價 使用標準價格 產品 產品 ID 記錄 ID 名稱 產品代碼 恰好一個 零個或一個 一個或多個 零個或多個 © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

有一條規則常讓人栽跟頭:存在一本標準價格手冊,任何其他價格手冊裡的價格手冊條目都可以直接使用產品的標準價格。在載入商機的產品之前,先弄清楚它用的是哪本價格手冊。

現在看看這棟房子的另一邊。同樣的客戶,同樣的連絡人。出了問題時,客戶會提交一個案例。

案例通常與客戶擁有的某樣東西有關,而 Salesforce 為此有一個物件:資產。在模組 5 裡,我會把它稱為人們容易忽視的標準物件。它是客戶擁有的東西,不管是不是從你這裡買的。

那麼客戶有權獲得什麼?這就是權利(Entitlement):一個客戶有資格獲得的支援,通常與某個資產、產品或服務合同相關聯。把一項權利放到案例上,案例就知道自己應該得到什麼級別的支援。

Service 模型 Service 模型。一個客戶有多個連絡人、案例和資產。連絡人回報案例。一個案例可以關於一個資產;而屬於某個客戶的權利(Entitlement)涵蓋多個案例。一條從案例繞過它的角、回到自己的線,就是上級案例(Parent Case):一個案例是零個或多個案例的上級,而每個案例有零個或一個上級。 有 有 回報 擁有 關於 涵蓋 上級 客戶 連絡人 資產 案例 權利 恰好一個 零個或一個 一個或多個 零個或多個 © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

看看那條從案例連回它自己的線。每個案例都有一個 Parent Case(上級案例)欄位,它指向另一個案例。這就是自查閱(self-lookup):從一個物件指向它自己的關係。很多人第一次看到它時都會困惑,所以下面是我使用它的兩個理由。

第一:一個大問題拆分成幾個小問題。客戶報告說整個安裝都癱了。我們為網路、硬體和配置分別開子案例,每個單獨處理,它們都向上彙總解決:所有子案例都解決之前,上級案例就不算完成。

第二:歷史。一個案例上個月已經關閉,現在同樣的問題又回來了。新案例指回原來的那個,所以任何開啟它的人都能看到這件事以前發生過,以及當時是怎麼處理的。

等到模組 7 講關係時,我們會再回到自查閱。

注意,客戶和連絡人在兩張圖裡都位於同一個位置。它們是同樣的記錄。銷售代表和服務專員看的是同一個客戶,只是從這棟房子的不同兩邊去看。這是堅持使用標準物件最有力的理由之一:這些模型本來就是為了相互銜接而構建的。

記錄上的東西並不都是欄位。合同、照片、PDF 和電子表格都是檔案,它們應該放在 Salesforce Files 裡,而不是舊的附件模型裡,那是遺留功能。如果文件已經存放在 SharePoint Online、OneDrive、Google Drive 或 Box 裡,Files Connect 可以讓使用者從 Salesforce 存取它,而無需把它複製進來。

檔案的計算方式和記錄不同。Salesforce 把儲存分成兩部分:檔案儲存存放附件、Files、Salesforce CRM Content、Chatter 檔案等,資料儲存存放你的記錄。當每條記錄都帶有照片或掃描件時,檔案儲存會增長得很快,所以大量圖片,比如來自現場應用的照片,往往完全應該放在 Salesforce 之外,Salesforce 只保留一個連結。模組 4 會再回到這一點。

資料儲存的計算方式也和資料庫不同。在普通資料庫裡,一張兩列、一百萬行的表很小,而一張一百列、一百萬行的表就是一頭大象。Salesforce 對它們一視同仁:**大多數記錄按大約 2 KB 計算,不管它有多少個欄位。**也有例外。市場活動算得更多,電子郵件訊息按實際大小計算,個人帳戶按大約 4 KB 計算,因為它既是客戶又是連絡人。

給你一個小技巧。每當我走進一個新的 org,最先去的地方之一就是設定 → Storage Usage(儲存使用情況)。我甚至會在第一次通話時就請客戶給我發一張截圖。那個介面不會撒謊。它告訴你哪些物件在增長,哪些已經是大象了。

客戶和連絡人模型非常適合一家公司以及公司裡的人。但如果你的客戶不是一家公司呢?如果是一個人呢?

這就是個人帳戶:把一個客戶和一個連絡人合併成一條記錄,用於個人。他們的連絡人欄位會一起帶過來,其中的自訂欄位會帶著自己的字尾 __pc 出現。每條個人帳戶同時佔用客戶和連絡人的儲存,因為在底層它兩者都是。

在你啟用它之前,先提醒一句:**個人帳戶一旦啟用,就無法停用。**這是第 1 章裡可逆性測試最純粹的形式。模組 5 會告訴你我對什麼時候值得用它的立場。

  • 在設計任何新東西之前,Salesforce 已經建模了業務的哪些部分。
  • 一個概念落在 Sales 模型、Service 模型,還是兩者都有,同時知道它們共用客戶和連絡人。
  • 文件和圖片放在哪裡:Salesforce Files、一個連線的檔案系統,還是放在平台之外並保留一個連結。
  • 這些資料在儲存上要花多少,按 Salesforce 的方式計算:按記錄,而不是按列。
  • 客戶是一家公司還是一個人,在開啟某個無法關閉的東西之前就弄清楚。

那麼當 Salesforce 沒有你需要的東西時呢?你自己構建。這是下一個模組的內容。