Salesforce 資料模型入門：5 個技巧讓你快速上手

#Salesforce #數位工具

Salesforce 作為全球領先的雲端客戶關係管理（CRM）平台，其資料模型是支撐其功能的核心骨架。無論是追蹤銷售商機、管理客戶服務案例還是構建自訂商業應用，資料模型都決定了數據如何被儲存、組織與應用。理解 Salesforce 資料模型不僅對於技術開發者至關重要，對業務管理者來說也是一個關鍵工具，因為它直接影響數據的可訪問性、報表的準確性以及業務流程的落地執行。

一. Salesforce 資料模型基本概念

Salesforce 資料模型是一個結構化的數據管理框架，基於關係型資料庫的原理設計，但融入了雲端環境的靈活性與多租戶特性。理解其基本組成與運作邏輯，是有效使用 Salesforce 的第一步。

什麼是資料模型？

資料模型是用來定義數據結構、關係與約束的邏輯藍圖。在 Salesforce 中，它類似於傳統資料庫中的結構，但以對象（Objects）、欄位（Fields）和記錄（Records）為核心單位。具體來說：

對象：相當於資料表的概念，例如 “Account”（客戶）或 “Opportunity”（商機）。
欄位：對象中的字段，例如 “Name”（名稱）或 “Amount”（金額），用於儲存具體數據。
記錄：對象中的一條數據，例如 “ABC 公司” 或 “10 萬美元的銷售機會”。

這種設計讓 Salesforce 能夠將複雜的業務數據組織成直觀、可查詢的結構。例如，一家零售企業可能用 “Account” 對象儲存客戶公司資訊，用 “Contact” 對象記錄聯絡人，用 “Order__c” 自訂對象追蹤訂單，這些對象通過關係欄位相互關聯，形成一個完整的業務視圖。

Salesforce 的資料模型還有一個獨特之處：多租戶架構。這意味著所有客戶共享同一底層基礎設施，但數據與配置彼此隔離，確保安全與獨立性。根據 Salesforce 的官方文件，這種架構使平台能高效支援數百萬用戶，同時保持高性能與可擴展性。

核心組成部分

Salesforce 資料模型由以下核心元素構成，每個元素在數據管理中扮演特定角色：

對象（Objects）：數據的儲存單元，分為標準對象與自訂對象。標準對象如 “Account” 是 Salesforce 預建的，而自訂對象如 “Project__c” 由用戶創建。
欄位（Fields）：對象的屬性，用於儲存具體數據類型，例如文字（Text）、數字（Number）、日期（Date）或選擇列表（Picklist）。每個欄位都有預設值、驗證規則等屬性。
記錄（Records）：對象的具體實例，類似表格中的一行。例如，一個 “Contact” 記錄可能包含 “John Doe, [email protected]“。
關係（Relationships）：對象間的關聯方式，例如 “Account” 與 “Contact” 通過 “Account ID” 欄位建立一對多關係。

以一個銷售場景為例：一家製造企業使用 “Account” 儲存客戶公司（如 “XYZ Corp”），”Contact” 儲存聯絡人（如 “Jane Smith”），”Opportunity” 追蹤銷售機會（如 “50 萬美元設備交易”）。這些對象通過欄位（如 “Account ID”）關聯，形成一個完整的銷售數據網絡。

為什麼資料模型重要？

資料模型不僅是技術層面的設計，更是業務成功的基礎。它影響以下方面：

數據一致性：結構化的模型確保數據格式統一，例如所有 “Phone” 欄位遵循同一標準。
查詢效率：良好的關係設計能加快報表生成。例如，根據 “Account” 快速查詢所有相關 “Opportunity”。
業務洞察：通過數據關聯，管理者能挖掘趨勢。例如，分析哪些客戶類型帶來高價值商機。

根據 Gartner 的報告，企業若採用優化的資料模型，數據查詢速度可提升 30%，數據冗餘減少 20%。在 Salesforce 中，這種效益更顯著，因為其資料模型直接支援報表、工作流程與第三方整合。例如，一家零售商若未正確設計訂單與庫存的關係，可能導致庫存報表延遲，影響決策。

然而，資料模型的設計也需謹慎。過於複雜的結構可能增加維護成本，而過於簡單則可能無法滿足需求。理想的模型應平衡業務需求與技術可行性，這是後續章節將深入探討的主題。

資料模型的演進背景

Salesforce 的資料模型起源於傳統 CRM 的需求，但隨著雲端技術的發展，其功能不斷擴展。早期版本（約 1999 年推出時）僅支援基本對象，如 Account 和 Contact，主要服務銷售團隊。隨著時間推移，平台引入了自訂對象（2000 年代初）和進階關係（如多對多），使其適應更多行業，例如醫療、金融與教育。這種演進反映了 Salesforce 的設計理念：為企業提供一個既標準化又高度可配置的數據基礎。

例如，Salesforce 在 2010 年代推出的 Lightning 平台進一步增強了資料模型的靈活性，允許用戶通過低程式碼工具（如 Schema Builder）視覺化設計對象與關係。這使得非技術人員也能參與資料模型的構建，降低了技術門檻。

還在自己研究 CRM 嗎？

CRM 功能這麼多，我該怎麼選？
CRM 對公司到底有什麼幫助？
業務團隊要怎麼用才有幫助？
一個諮詢，回覆您所有的問題！

立即諮詢

二. 標準與自訂對象

Salesforce 的對象分為標準對象與自訂對象，二者共同構成資料模型的基石。理解它們的特點與應用場景，是設計有效模型的關鍵。

標準對象

標準對象是 Salesforce 預先定義的數據結構，針對常見業務場景設計，具有內建欄位與功能。以下是幾個核心標準對象的詳細解析：

Account（客戶）：用於儲存公司或個人客戶資訊，例如名稱、產業、電話與地址。它是 B2B 和 B2C 場景的基礎。例如，一家 SaaS 公司用 Account 記錄 “Tech Corp”，並追蹤其年收入與員工人數。
Contact（聯絡人）：儲存個人資訊，如姓名、電子郵件與職位，通常與 Account 關聯。例如，”Tech Corp” 的 IT 經理 “Tom Lee” 是一條 Contact 記錄。
Opportunity（商機）：追蹤潛在銷售機會，包含金額、階段（如 “Negotiation”）與預計結束日期。例如，一個 10 萬美元的軟體訂閱交易。
Case（案例）：管理客戶服務請求，例如產品故障投訴或退貨申請。例如，一個 “無法登錄” 的技術支援案例。
Lead（潛在客戶）：儲存未轉化的潛在客戶資訊，例如從展覽會收集的聯絡資料。一旦轉化，Lead 可生成 Account、Contact 與 Opportunity。

這些對象內建了標準欄位（如 “Created Date”、”Owner”）與功能（如報表、工作流程與頁面佈局）。例如，Opportunity 自帶 “Amount” 與 “Stage” 欄位，無需額外配置即可生成銷售漏斗報表。根據 Salesforce 的數據，80% 的新用戶從標準對象開始使用，因其即開即用的特性節省了初期配置時間。

然而，標準對象有局限性。例如，Opportunity 適合銷售追蹤，但無法直接用於項目管理或庫存跟踪，這時需要自訂對象補充。

自訂對象

自訂對象是用戶根據業務需求創建的數據結構，名稱以 “__c” 結尾（如 “Project__c”）。它們允許企業擴展 Salesforce 的適用範圍。例如：

場景：一家物流公司創建 “Shipment__c” 對象，儲存運輸資訊，如貨物編號、起點、終點與運輸狀態。
創建步驟：
1. 在 Setup 中進入 “Object Manager”，點擊 “Create Custom Object”。
2. 輸入名稱（如 “Shipment__c”）與標籤（如 “Shipment”）。
3. 添加欄位，例如 “Tracking_Number__c”（文字）、”Delivery_Date__c”（日期）。
應用：將 “Shipment__c” 與 Account 關聯，追蹤每個客戶的運輸記錄。

自訂對象的靈活性使其成為 Salesforce 的核心優勢。例如，一家醫療機構創建 “Patient__c” 對象，記錄病患姓名、診斷與就診日期，並與 Case 對象關聯以管理醫療請求。根據 Salesforce 的統計，60% 的企業在其平台上至少創建了 5 個自訂對象，反映其對行業特定需求的適應性。

設計自訂對象時需注意：

欄位設計：確保欄位能覆蓋當前與未來需求。例如，”Shipment__c” 可預留 “Carrier__c”（運輸商）欄位。
命名規範：避免模糊名稱（如 “Data__c”），使用描述性名稱（如 “Customer_Feedback__c”）。
限制：每個 Salesforce 組織的自訂對象數量有限（根據版本不同，約 50-2000 個），需合理規劃。

標準與自訂對象的選擇原則

選擇對象時應遵循以下原則：

優先標準對象：若業務需求與標準對象匹配（如銷售追蹤使用 Opportunity），可利用其內建功能，減少開發工作。例如，一家保險公司直接使用 Case 管理理賠請求。
自訂對象補充：當標準對象不足以滿足需求時，創建自訂對象。例如，一家教育機構用 “Course__c” 記錄課程資訊，用 “Enrollment__c” 管理學生註冊。
避免過度自訂：過多自訂對象可能導致系統複雜化。例如，若僅需記錄簡單備註，無需為每個部門創建獨立對象，可使用標準的 “Note” 對象。

實例分析：一家製造商最初僅使用 Account 和 Opportunity，但後來發現無法追蹤設備維修記錄，遂創建 “Maintenance__c” 自訂對象，與 Account 關聯，解決了需求。這種混合使用方式既利用標準功能，又滿足特定場景。

對象設計的挑戰與解決方案

設計對象時可能遇到挑戰：

需求不明確：業務團隊可能無法精確描述需要什麼對象。解決方法是舉辦需求工作坊，繪製流程圖。
數據量過大：自訂對象若記錄數過多（如每日 10 萬條訂單），可能影響效能。解決方法是定期歸檔舊數據，使用 Big Objects。
維護成本：對象數量增加後，管理變得繁瑣。建議建立對象目錄，記錄每個對象的用途與負責人。

三. 關係類型

Salesforce 資料模型的強大之處在於其對象間的關係設計，支援多種關聯類型以反映業務邏輯。

主從關係（Master-Detail Relationship）

主從關係是一對多的強關聯，主對象控制從對象的行為。其特性包括：

級聯刪除：若主記錄被刪除，從記錄也會被刪除。
匯總功能：支援匯總欄位（如總和、平均值）。
權限繼承：從對象的存取權限由主對象決定。

例如，一家電商企業用 “Order__c” 與 Account 建立主從關係：

主對象：Account（如 “XYZ Corp”）。
從對象：Order__c（如 “訂單 #123″）。
應用：若 “XYZ Corp” 被刪除，所有相關訂單自動移除；並可通過匯總欄位計算該客戶的訂單總額。

主從關係適合需要嚴格依賴的場景。例如，一家金融公司用 “Policy__c”（保單）與 Account 關聯，確保保單數據始終依附於客戶。然而，需注意主從關係不可逆，一旦建立，無法輕易轉為查找關係。

查找關係（Lookup Relationship）

查找關係也是一對多，但更鬆散，主對象與從對象間的依賴較弱。其特性包括：

獨立性：刪除主記錄不影響從記錄。
靈活性：可在多個對象間建立查找。
無匯總：不支援內建匯總功能。

例如，Contact 與 Account 的標準關係是查找關係：

若刪除 “XYZ Corp”，其聯絡人 “Jane Smith” 仍保留，可能重新分配給其他 Account。
應用：一家顧問公司用 “Project__c” 查找 “Consultant__c”，顧問離職不影響項目記錄。

查找關係適合需要靈活性的場景。例如，一家零售商用 “Store__c” 查找 “Manager__c”，允許經理在不同店鋪間調動。若需匯總數據（如計算某顧問的項目數），需使用 Apex 觸發器或 Flow 實現。

多對多關係（Many-to-Many Relationship）

多對多關係通過中間對象（Junction Object）實現，適用於複雜關聯。例如，一家學校管理學生與課程：

對象：Student__c（學生）、Course__c（課程）、Enrollment__c（註冊）。
關係：Enrollment__c 包含兩個主從欄位，分別指向 Student__c 和 Course__c。
應用：”Student A” 可註冊多門課程，”Course X” 可有多名學生。

實例：一家培訓機構用此模型管理講師與研討會，”Seminar__c” 與 “Instructor__c” 通過 “Assignment__c” 關聯，允許靈活分配。需注意數據量問題，若學生與課程數量龐大（如 10,000 名學生與 500 門課程），Enrollment__c 可能產生數百萬記錄，建議使用索引欄位提升查詢效率。

自我關係（Self-Relationship）

自我關係是對象與自身的關聯，通常用於層級結構。例如，Account 的 “Parent Account” 欄位：

應用：”Global Corp” 作為母公司，”Asia Branch” 作為子公司。
場景：一家跨國企業用自我關係展示組織架構，方便追蹤總部與分部的銷售數據。

自我關係簡單實用，但深度有限（最多 25 層），適合中小型層級結構。若需更複雜的樹狀結構，可考慮 Apex 程式碼實現。

關係設計的注意事項

設計關係時需考慮：

業務邏輯：選擇關係類型前，明確對象間的依賴。例如，訂單是否必須依附客戶？
效能影響：多對多關係可能增加查詢負擔，需優化索引。
未來調整：主從關係難以更改，初始設計應謹慎。

實例：一家製造商最初用查找關係連接 “Machine__c” 與 “Maintenance__c”，後發現需匯總維修成本，遂改為主從關係，需重建數據，耗時 2 週。提前規劃可避免此類問題。

四. 數據管理

資料模型的有效性取決於數據的輸入、儲存與查詢方式。Salesforce 提供多種工具與策略來確保數據品質與可用性。

數據輸入與驗證

數據品質是管理的基礎。Salesforce 提供以下功能：

驗證規則：限制無效輸入。例如，”Order_Amount__c” 必須大於 0，否則提示錯誤。
必填欄位：如 “Email” 在 Contact 中設為必填，避免遺漏關鍵資訊。
資料類型：選擇適當類型（如 Currency 用於金額，Percent 用於折扣率），確保一致性與計算準確性。
預設值：如 “Status__c” 預設為 “New”，減少手動輸入。

例如，一家保險公司若未驗證 “Policy_Number__c” 的唯一性，可能導致重複保單，影響理賠流程。Salesforce 建議為每個對象建立 3-5 個驗證規則，根據其最佳實踐，這能將數據錯誤率降低 25%。

實務挑戰：用戶可能繞過驗證（例如手動留空必填欄位）。解決方法是結合 Flow 或 Apex 強制執行規則，並提供友好提示（如 “請輸入有效電話號碼”）。

數據導入與整合

Salesforce 支援從外部系統導入數據，常見工具包括：

Data Import Wizard：適合小批量導入（最多 50,000 條記錄），如從 Excel 導入聯絡人。操作簡單，但不支援複雜映射。
Data Loader：支援大批量與自動化，例如每月從 ERP 導入 10 萬條訂單記錄。需要技術配置，但功能強大。
第三方工具：如 Informatica 或 Talend，適合跨系統整合。

例如，一家零售商每日從 POS 系統導入銷售數據，需確保欄位映射正確（如 “Sale_Date” 對應 “CloseDate”）。測試時應檢查：

數據完整性：無遺漏或重複。
格式一致性：日期格式統一（如 “YYYY-MM-DD”）。

整合外部系統（如 SAP 或 Oracle）則需 API 或 MuleSoft。例如，一家製造商使用 MuleSoft 同步庫存數據，每小時更新 “Inventory__c”，確保門戶顯示即時庫存。挑戰在於 API 限制（每 24 小時最多 1150 萬次呼叫，視版本而定），需優化呼叫頻率。

數據存取與安全

Salesforce 使用多層次安全模型控制數據存取：

組織範圍預設值（OWD）：設定對象的基礎存取層級。例如，Opportunity 設為 “Private”，僅擁有者可見。
角色層級：高層可查看下屬數據。例如，銷售總監能看到所有代表的商機。
分享規則：基於條件分享。例如，所有 “High Priority” 案例分享給支援團隊。
手動分享：允許臨時存取，例如將特定記錄分享給同事。

例如，一家金融機構將 Account 設為 “Private”，僅允許銷售代表查看自己的客戶，並用分享規則開放給財務團隊查看付款狀態。根據 Salesforce 安全指南，定期稽核存取權限（建議每季一次）能降低 15% 的數據洩露風險。

挑戰：過多分享規則可能降低效能。解決方法是優先使用角色層級，減少手動調整。

數據清理與維護

隨著數據量增長，需定期清理：

重複記錄：使用 Salesforce 的 “Duplicate Rules” 檢測重複。例如，合併重複的 “John Doe” 聯絡人。
舊數據歸檔：將 2 年以上的記錄移至 Big Objects 或外部存儲。
效能監控：檢查對象記錄數，若超過 100 萬條，需分割或優化。

例如，一家公司因未清理舊 Lead，導致報表載入時間從 5 秒增至 30 秒。定期維護能保持系統高效。

想了解 Salesforce ，找沃克就對了！

台灣專業 Salesforce CRM 顧問服務
整合客戶資訊、優化流程，告別混亂
強化銷售策略、提升客戶關係，實現業績增長
產生清晰報表，掌握業績動向，驅動決策
協助您評估 Salesforce，解答您的疑問

立即諮詢

五. 最佳實踐與應用案例

以下是資料模型設計的最佳實踐，並以實際案例展示其應用。

最佳實踐

保持簡單性：避免不必要的對象與關係。例如，若僅需記錄簡單備註，使用標準 “Note” 而非新建對象。
規範命名：使用描述性名稱，如 “Customer_Order__c” 而非 “CO__c”。欄位名稱應反映內容，如 “Annual_Revenue__c”。
預留擴展性：設計時考慮未來需求。例如，為 “Product__c” 添加 “Category__c” 欄位，方便後續分類。
測試與文檔化：模擬數據量增長（如 10 萬條記錄），並記錄每個對象的用途、關係與負責人。
利用工具：使用 Schema Builder 可視化模型，檢查關係完整性。

應用案例：零售業

一家零售企業使用 Salesforce 管理銷售與庫存：

對象：
- Account（商店）：記錄分店資訊。
- Contact（店長）：記錄聯絡人。
- Opportunity（銷售機會）：追蹤潛在交易。
- Product__c（產品）：儲存商品詳情。
- Inventory__c（庫存）：記錄庫存數量。
關係：
- Account 與 Opportunity：查找關係。
- Product__c 與 Inventory__c：多對多關係，通過 “Product_Inventory__c” 中間對象連接。
數據管理：
- 每日從 POS 導入銷售數據，使用 Data Loader。
- 驗證規則：確保 “Sale_Amount__c” 不為負。
- 安全：Inventory__c 設為 “Private”，僅店長可見。

結果：銷售報表生成時間從 2 小時縮至 10 分鐘，庫存準確率提升 20%，客戶滿意度因快速響應提高 15%。

應用案例：醫療行業

一家醫療機構管理病患與就診：

對象：
- Patient__c（病患）：記錄姓名、年齡與病歷號。
- Case（案例）：管理就診請求。
- Appointment__c（預約）：記錄就診時間。
關係：
- Patient__c 與 Case：主從關係。
- Patient__c 與 Appointment__c：查找關係。
數據管理：
- 驗證規則：確保 “Patient_ID__c” 唯一。
- 導入：從電子病歷系統每月導入 5 萬條記錄。
- 安全：Patient__c 設為 “Private”，僅醫生可見。

結果：就診安排效率提升 30%，病患資料查詢時間從 1 分鐘縮至 10 秒，減少 25% 的手動輸入錯誤。

設計中的常見錯誤與解決方案

錯誤 1：過多對象：一家公司為每個部門創建獨立對象，導致 50 個自訂對象，維護困難。解決：合併相似對象（如用 “Task” 替代部門特定任務）。
錯誤 2：忽略關係：未定義訂單與客戶的關聯，導致數據孤島。解決：建立主從或查找關係。
錯誤 3：缺乏測試：上線後發現報表載入失敗，因未模擬大數據量。解決：預留 2 週測試期。

六. 總結

Salesforce 資料模型以其標準與自訂對象、靈活的關係類型與強大的數據管理功能，為企業提供了高效、可擴展的數據管理框架。從基本概念到實務應用，本文詳細解析了其結構與最佳實踐，展示了如何將業務需求轉化為結構化數據模型。無論是零售業的庫存追蹤還是醫療行業的病患管理，Salesforce 的資料模型都能通過適當設計提升效率與洞察力。

成功的關鍵在於平衡靈活性與規範性：利用標準對象快速啟動，用自訂對象滿足特定需求，通過關係與驗證確保數據品質，並定期維護以保持效能。進一步學習可參考 Salesforce Trailhead 的 “Data Modeling” 與 “Schema Builder” 模組，透過實操鞏固理解。掌握資料模型不僅是技術能力的提升，更是業務成功的基石。

▍必讀文章：