Salesforce 與外部分析平台之間的大多數企業整合管道都依賴自訂程式碼。它們會運作直到發生損壞為止。結構描述漂移、API 耗用和實刪除間隙需要持續的工程介入。隨著公司推動使用敏捷、公民開發人員啟用的結構,此模型會變成瓶頸:分析小組等待工程衝刺將 Salesforce 欄位新增至下游結構描述、失敗的每晚載入會延遲週一上午的報告,而簡單的組態變更需要程式碼檢閱與部署。

CRM Analytics 是 Salesforce 原生分析和商業情報平台,可讓公司探索資料、建立互動式顯示面板,並在不離開 Salesforce 生態系統的情況下發現 AI 驅動的洞察,藉此解決此問題。此功能的中心是原生內建在平台中的陳述性低程式碼資料同步功能:CRM Analytics SyncOut 和 CRM Analytics SyncIn。

CRM Analytics SyncOut 會根據設定的排程將 Salesforce 記錄移至外部資料存放區,使用變更資料擷取 (CDC) 進行增量載入和內建實刪除追蹤,以將永久移除的記錄標記。CRM Analytics SyncIn 會將外部資料帶回 Salesforce、將資料欄對應至物件欄位,並使用大量 API 2.0 更新插入記錄。這兩者都完全透過 Salesforce 設定進行設定。沒有管道、暫存指令檔、無自訂監視。管理員可在單一「設定」工作階段中設定同步化工作;平台會自動處理執行、重試、錯誤記錄和結構描述對應。

本指南說明模式、使用時機、如何使用 Snowflake 作為實作範例,以及判斷模式是否符合指定整合問題的結構考量事項。

**授權備註:**沒有 CRM Analytics 授權附加元件的基底 Salesforce 版本無法使用 CRM Analytics SyncIn 和 SyncOut。請先確認授權權益,再設計依據這些功能的同步化結構。

資料整合是企業結構中具有最高摩擦性的表面之一。從 Salesforce 到分析平台的自訂 ETL 銷售管道通常需要「連線的應用程式」進行驗證、SOQL 解壓的排程工作、協調欄位類型的轉換層、大量載入的暫存區域,以及用於找出失敗的監視層。自訂程式碼的每個元件皆代表失敗點。

此摩擦組合隨著時間的成本。Salesforce 中的結構描述漂移 (重新命名的欄位、新的選項清單值、變更的 API 名稱) 會無聲地中斷銷售管道。在使用量高峰期間的 API 耗用會使解壓延。實刪除的記錄永遠不會顯示在目標表格中,進而讓下游分析視為即時的過時資料。工程小組會成為例行資料作業的瓶頸。

CRM Analytics SyncIn 與 SyncOut 會變更作業模型。組態會取代程式碼。平台負責執行、錯誤處理、結構描述對應和可觀察性。管理員可以定義、修改和監視同步化工作,而無須提出開發票證。

此新作業模型的結果是減少從整合設計到作業同步的時間、降低工程負擔,以及在平台限制內調整整合模型,而不需要自訂程式碼維護。

SyncIn 和 SyncOut 是 CRM Analytics 資料同步化的兩個方向模式。SyncOut 會將 Salesforce 記錄移至外部平台。SyncIn 會將外部記錄帶入 Salesforce。兩者都會在不需要自訂程式碼的陳述性組態模型上作業。

陳述性組態表示所有同步化行為都會透過 Salesforce 設定中的點選使用者介面定義。來源物件、目標表格、欄位對應、同步化排程、同步化模式和篩選條件皆可透過組態中繼資料設定。平台會從該中繼資料衍生執行計畫,並逐步管理。

完整同步和增量同步控制每次執行時移動的資料。完整同步化會在每次執行上查詢符合篩選條件的所有記錄。增量同步化會使用 CDC 來僅查詢自上次執行後變更的記錄。增量同步是大量物件的建議模式,因為其會大幅減少 API 耗用與同步持續時間。

變更資料摘取 (CDC) 是 Salesforce 平台功能,可將物件的欄位級變更記錄為事件串流。SyncOut 使用 CDC 來偵測建立、更新和刪除,而無須執行完整表格掃描。CDC 必須在 Salesforce 設定中為每個物件啟用,才能由同步化組態參照。

實刪除追蹤可解決 Salesforce 對外 ETL 中最持續的一個問題。在 Salesforce 中實刪除記錄時,記錄會從標準 SOQL 查詢中消失。若沒有明確追蹤,外部平台永遠不會知道記錄已移除。當啟用時,SyncOut 的實刪除追蹤會使用 DEL_FLAG = 'Y' 標記在目標表格中刪除的記錄,讓下游系統能提供可靠的訊號來篩選過時的資料。

同步化頻率可設定為每週 15 分鐘。選擇的選項是資料更新、API 耗用與 Snowflake 倉庫計算成本之間的權衡。作業顯示面板的 15 分鐘同步近乎即時,每日同步適用於批次報告工作量。

**管理員限制會限制同步化工作設計:**Salesforce API 要求限制 (Unlimited Edition 每 24 小時 15,000 次呼叫)、大量 API 2.0 批次大小為 10,000 筆記錄,以及每個交易 50,000 個 SOQL 查詢列限制,都會告知您如何調整和排程同步化工作。平台會自動處理切分與分頁,但結構設計師必須考量在組織中執行之所有同步工作的有限主機空間。

Snowflake 是使用 Salesforce CRM Analytics 進行資料同步化的主要目標和來源。此範例可作為批次與增量資料移動如何逐步運作的具體範例。

本節提供使用 Snowflake 作為外部分析平台實作 CRM Analytics SyncOut 和 SyncIn 的概觀。它涵蓋每個方法、共用驗證模型、安全性架構、關鍵平台考量事項和可觀察性作法。

在此 SyncOut 組態中,Salesforce 使用 CRM Analytics SyncOut 將記錄推送至 Snowflake。平台會透過 SOQL 提取資料、自動處理類型轉換,並依照設定的排程 (從 15 分鐘到每週) 將資料載入至 Snowflake 表格。如需特定載入語意,請參閱目前的 Salesforce 和 Snowflake 文件。

SyncOut 結構

在此 SyncIn 組態中,Salesforce 使用 CRM Analytics SyncIn 將資料提取回 Salesforce。平台會透過 Statements API 查詢 Snowflake,並使用大量 API 2.0 將結果更新插入 Salesforce。大型結果集會自動分頁以保持在 API 限制之內。同步會依照設定的排程執行,從 15 分鐘到每週。

同步化結構

Salesforce 同步化支援多個驗證方法,以安全地與 Snowflake 連線。企業整合的兩個主要方法為金鑰組 (私人金鑰) 和委派的 OAuth 2.0。

方法 1:金鑰組驗證 (私人金鑰):金鑰組驗證是自動化系統對系統資料移動 (例如 CRM Analytics SyncIn 和 SyncOut) 的建議方法。驗證依賴 JSON Web 權杖 (JWT),而非密碼或可重新整理權杖,因此非常適合不需要權杖重新整理的未受監視且已排程工作。

  • **Salesforce 憑證:**產生私人金鑰並安全地將其儲存在 Salesforce 憑證與金鑰管理中。
  • **外部/已命名認證:**設定為使用 JWT 交換。Salesforce 使用儲存的私人金鑰簽署輸出連線要求。
  • **Snowflake 使用者公用金鑰:**相符的公用金鑰會直接指派給專屬的 Snowflake 服務帳戶 (例如 ALTER USER CRM_ANALYTICS_SYNC_USER SET RSA_PUBLIC_KEY = ’…’)。Snowflake 接著會使用此金鑰來驗證傳入的 JWT 簽章。此方法不需要「安全性」整合。

**方法 2:委派的 OAuth 2.0 驗證:**或者,Salesforce 可以使用 OAuth 操作來進行驗證。關鍵元件包括:

  • **驗證提供者:**透過 Snowflake 管理 OAuth 處理,方法是使用從 Snowflake 安全性整合取得的用戶端認證。
  • **外部認證:**在 Salesforce 中安全保留 OAuth 權杖,並自動將其注入至同步呼叫。
  • **已命名認證:**定義 Snowflake 端點 URL (例如,https://<account>.snowflakecomputing.com),並參照外部認證。
  • **Snowflake 安全性整合:**在 Snowflake 中將 Salesforce 註冊為信任的 OAuth 用戶端 (OAUTH_CLIENT = CUSTOM)。定義允許的重新導向 URI 並啟用重新整理權杖。

**組態相依性:**無論選擇的方法為何,這些元件都會形成一個連接同步化組態至端點的相依性鏈。必須將「已命名認證」的存取權授與相關的 Salesforce 設定檔;若沒有此存取權,無論其他所有組態為何,同步工作都會因為驗證錯誤而失敗。

背景同步化依賴單一整合身分。

  • **專屬服務帳戶:**建立具有最低權限角色的專屬 Snowflake 服務帳戶,其範圍僅限於同步所需的資料庫、結構描述和表格。
  • **細微權限:**針對 SyncOut,此角色需要在目標表格上進行 INSERT、UPDATE 和 SELECT。請勿使用高權限角色,例如 ACCOUNTADMIN、SECURITYADMIN 或 SYSADMIN。
  • **管理員限制與切分:**同步化期間,系統會自動切分大型結果集,以遵循 Salesforce SOQL 管理員限制。SyncIn 會透過自動分頁從 Snowflake 陳述式 API 提取大型結果集,以有效管理資料量。
  • **變更資料接收 (CDC):**增量 SyncOut 依賴 Salesforce CDC 事件串流來識別已建立、已更新或已刪除的記錄。如果已啟用實刪除追蹤,則不會捨棄已刪除的 Salesforce 記錄,但會在 Snowflake 中以 DEL_FLAG = 'Y' 標記。
  • **更新插入限制:**SyncIn 依賴大量 API 2.0 將資料載入回 Salesforce。這需要在目標 Salesforce 物件上設定指定「外部識別碼」欄位,以作為更新插入索引鍵。
  • **設計指引:**一律從精密設計的 Snowflake 檢視同步化,而非從原始表格同步化。檢視允許列的預先篩選、欄選取和應用業務邏輯,並根據套用的預先篩選減少資料量、同步持續時間,以及 Snowflake 倉庫計算成本。

每個同步化執行都會產生全方位稽核追蹤,以驗證資料移動。「同步化工作監視器」顯示面板提供 SyncIn 與 SyncOut 的即時狀態、已處理記錄計數、執行持續時間,以及詳細的錯誤記錄。在 Snowflake 端,Salesforce 提交的每個查詢都會記錄在 Snowflake 查詢歷程記錄中,提供執行延遲、掃描的列和倉庫運算用量的完整可視性。此外,結構設計師會定義專屬的 Snowflake 稽核表格,以取用時間戳記、記錄計數和錯誤的同步執行中繼資料;這些項目並非由平台自動產生。針對端對端驗證,請在兩個平台之間比較記錄計數:確認 SyncOut 執行的 Snowflake (WHERE DEL_FLAG = 'N') 啟用中記錄,並直接根據 SyncIn 執行的原始 Snowflake 來源檢視比較 Salesforce 目標物件計數。

以下情況使用 CRM Analytics SyncIn 和 SyncOut:

  • **雙向同步是下列需求:**資料會透過 SyncIn 流入 Salesforce,並透過 SyncOut 流出至外部平台。
  • **實刪除追蹤十分重要:**SyncOut 的內建標記可解決歷史上複雜的 ETL 問題,無須自訂協調邏輯。
  • **CDC 型增量同步可行:**針對大量 Salesforce 物件,CDC 會大幅減少 API 耗用與同步持續時間,相較於完整掃描。
  • **排程的批次同步符合延遲需求:**最短同步化頻率為 15 分鐘,適用於作業顯示面板和近乎即時分析報告。
  • **低營運負擔優先順序為:**內建的顯示面板提供完整的同步化可視性,無須自訂記錄或警示基礎結構,陳述性「設定」UI 可讓管理員定義、修改和監視同步化工作,而無須提出開發票證。

在下列情況下請勿使用此模式:

  • **需要複雜轉換:**在同步化之前或之後,在 Snowflake 檢視或專屬轉換層中進行多個表格聯結、JSON 剖析或處理進階業務邏輯。
  • **需要 15 分鐘以下的延遲:**針對即時使用個案,請使用「平台事件」或「串流 API」。
  • **非常大量的串流工作量位於範圍中:**具有每小時數百萬筆交易的物件,可由專屬串流管道 (Kafka、平台事件) 提供更好的服務。
  • **需要自訂錯誤處理邏輯:**平台提供標準重試與錯誤記錄。複雜的重試模式或自訂警示需要 Apex 或外部協調流程。
  • **多組織或跨雲端同步化:**CRM Analytics SyncIn 與 SyncOut 可在單一 Salesforce 組織內運作。多組織案例需要 MuleSoft 或自訂整合層。

小組執行複雜的 ETL 管道,將 Snowflake 分析資料上載至 CRM Analytics 資料集。銷售管道速度緩慢、脆弱,且需要不斷的工程維護。

CRM Analytics SyncIn 已設定為將精密設計的 Snowflake 彙總檢視直接同步化至 Salesforce 自訂物件。小組重新設定 CRM Analytics 顯示面板以從這些物件 (而非 CRM Analytics 資料集) 讀取。結果:已去除兩個 ETL 銷售管道、同步持續時間從四個小時減少到 30 分鐘,以及管理員能夠修改同步組態而無需提出工程票證。

資料小組需要在其 Snowflake 作業資料存放區中追蹤實刪除的 Salesforce 記錄。傳統方法需要分割工作和複雜的識別碼協調邏輯,執行時間花費數小時,且結構描述變更很脆弱。

小組已設定 CRM Analytics SyncOut,且 CDC 已啟用實刪除追蹤。刪除的記錄現在會在 Snowflake 耗用量表格中自動以 DEL_FLAG = ‘Y’ 標記。下游分析查詢會套用 WHERE DEL_FLAG = ‘N’ 以僅查看啟用的記錄。協調邏輯已完全消除,同步化持續時間從 8 小時減少到 15 分鐘的增量執行。

在收購期間,收購公司將六個大量 Salesforce 物件同步至 Snowflake,以在固定時間表內進行跨組織報告和法規合規。

小組已針對具有 CDC 型增量同步的全部六個物件設定 CRM Analytics SyncOut。稽核中繼資料表格會追蹤整合期間的結構描述變更和記錄計數。他們未撰寫任何自訂程式碼。資料新鮮度從每日到 15 分鐘的間隔改善,且稽核中繼資料表格提供合規性報告所需的可追溯性。

同步化工作會共用組織的 API 預算。針對大型物件執行許多高頻同步工作的組織可能會耗盡每 24 小時 15,000 個 API 呼叫的限制。庫存所有同步化工作、估計每次執行的 API 耗用,以及暫存排程以散佈負載。針對具有低至中度變更率的物件,與完整同步相比,以 CDC 為基礎的增量模式可大幅減少每次執行的 API 耗用。

SyncIn 和 SyncOut 會針對 Snowflake 倉庫執行查詢和資料載入,進而耗用運算信用。針對簡單的 SELECT 查詢,X-Small 或 Small 倉庫通常是足夠的。針對大型 SyncOut 載入,可能需要「中」或「大」。在倉庫上設定自動暫停 (5 分鐘閒置) 和自動恢復。針對生產同步化工作使用專屬倉庫,以隔離成本並避免使用者查詢爭用。

如果 Salesforce 欄位重新命名、移除或變更 API 名稱,則對應的 SyncOut 欄位對應會無訊息失敗或記錄錯誤。建立變更管理流程,其中包含檢閱已啟用同步化組態作為任何 Salesforce 中繼資料變更的一部分。Snowflake 稽核表格提供變更歷程記錄,可協助識別何時發生漂移事件。

SyncOut 中的實刪除追蹤需要在 Salesforce 物件上啟用 CDC。如果未啟用 CDC,則「追蹤實刪除」選項不會生效。驗證 CDC 啟用作為同步化組態檢查清單的一部分,特別是在初始設定期間或在組織移轉後。

最常見的失敗類別是認證到期或權限遺失。「已命名認證」必須保持有效,且 Snowflake 服務帳戶必須保留其倉庫用量授與和表格權限。針對以 OAuth 為基礎的設定,權杖重新整理失敗會無聲地拖延同步化工作。監視「同步化工作監視」顯示面板是否有驗證錯誤模式,並針對工作失敗設定 Chatter 或電子郵件通知。

SyncIn 使用 Salesforce 外部識別碼欄位作為更新插入索引鍵。如果來源 Snowflake 檢視在索引鍵欄位上包含重複的值,則更新插入會針對受影響的記錄失敗。在金鑰欄位到達同步化組態之前,在 Snowflake 檢視層中強制執行金鑰欄位的唯一性。

同步化工作失敗時,平台會在「同步化工作監視器」中記錄每個記錄的詳細錯誤訊息。常見失敗案例及其解決方法:

  • **驗證失敗:**確認「已命名認證」狀態和 Snowflake 帳戶到期。如果權杖重新整理失敗,請重新驗證 OAuth。
  • **欄位對應錯誤:**檢查 Snowflake 欄與 Salesforce 欄位之間的類型相容性。檢閱執行中使用者的欄位級安全性。
  • **超過管理員限制:**減少同步化頻率或移至增量 CDC 模式以散佈 API 耗用。
  • **暫停 Snowflake 倉庫:**在倉庫上設定自動恢復,或在下一次排程的同步化之前觸發手動恢復。
  • **實刪除追蹤無法運作:**確認已在物件上啟用 CDC,且同步化組態中已設定「追蹤實刪除」標記。

CRM Analytics 資料同步化與 Salesforce 良好結構架構的多個支柱保持一致。

  • **可靠性 (錯誤容忍):**平台會自動管理執行、重試邏輯和部分失敗處理。失敗的記錄會在「同步化工作監視器」中個別記錄。在失敗後實作記錄計數協調以確認一致性、補充失敗通知,並監視「同步化工作監視器」是否有循環錯誤模式。透過限制範圍中的資料視窗,以 CDC 為基礎的增量同步化可減少失敗執行的爆炸半徑。
  • **Trust:**認證模型 (已命名認證、外部認證、驗證提供者) 會強制執行加密儲存、自動權杖重新整理和集中管理。Snowflake 端的最低權限存取權會限制已入侵認證的爆炸半徑。同步化期間會強制執行欄位級安全性;使用者無法同步化未獲授權存取的欄位。
  • **資源和成本最佳化:**增量 CDC 模式是效能最佳化的主要杠杆。相較於完整同步化,其會減少 API 耗用、同步化持續時間和 Snowflake 運算成本。Snowflake 檢視預先篩選可進一步減少傳輸中的資料量。倉庫自動暫停可防止閒置運算支出。
  • **傑出作業:**陳述性組態模型表示同步化工作是在中繼資料中定義的,而非程式碼中定義的。這可供稽核、複製和管理,無須工程參與。內建監視顯示面板在沒有自訂記錄基礎結構的情況下提供完整的可觀察性。
  • **可靠性 (延展性):**平台會自動處理切分、分頁和大量 API 批次。針對記錄量非常高的物件,增量 CDC 模式和離峰排程是維護管理員限制內輸送量的主要結構杠杆。

此檢查清單涵蓋設定和驗證同步化組態的最小步驟。

預先設定檢查清單:

  • 針對適用於 SyncOut 增量模式的所有 Salesforce 物件啟用「變更 資料擷取」(設定 → 變更 資料擷取。
  • 建立具有最低權限角色的專屬 Snowflake 服務帳戶;僅授與必要的表格和倉庫權限。
  • 如果使用 OAuth 驗證,請建立 Snowflake 安全性整合。
  • 識別 SyncIn 會作為更新插入索引鍵使用的每個 Salesforce 物件上的「外部識別碼」欄位;確認來源資料的唯一性。

連接性:

  • 在 Salesforce 中建立驗證提供者 (設定 → 驗證提供者)。
  • 建立外部認證並連結至驗證提供者 (設定 → 已命名認證 → 外部認證)。
  • 建立已命名認證並連結至「外部認證」(設定 → 已命名認證)。
  • 將「已命名認證」存取權授與相關 Salesforce 設定檔。

SyncOut 組態:

  • 建立 Snowflake 連線 (設定 → Analytics Studio → 資料管理員 → 連線 → Snowflake 連線)。
  • 建立 SyncOut 組態:來源物件、目標表格、同步模式、欄位對應、CDC、實刪除追蹤、排程。
  • 從每日同步化開始;在增加頻率之前,請先驗證資料品質與效能。

SyncIn 組態:

  • 建立外部資料來源 (設定 → Analytics Studio → 資料管理員 → 連線 → Snowflake 連線)。
  • 建立 SyncIn 組態:來源檢視、目標物件、外部識別碼欄位、欄位對應、排程。
  • 從 Snowflake 檢視同步化,而不是從原始表格同步化。

驗證:

  • 第一次執行後檢閱「同步化工作監視器」 (設定 → Analytics Studio → 資料管理員 → 同步化工作監視器)。
  • 查詢 Snowflake 稽核表格以確認已寫入同步化中繼資料。
  • 確認 DEL_FLAG 欄已存在並填入,以驗證實刪除標記。
  • 比較來源與目標之間的記錄計數。
  • 透過 Chatter 或電子郵件設定失敗通知。

當排程的批次同步符合延遲需求、需要雙向資料流程,以及減少對整合作業的工程相依性為優先順序時,請使用此模式。

本指南中的 Snowflake 工作範例說明完整的生命週期:連線設定、組態、執行流程和驗證。相同的原則也適用於任何支援的外部資料平台。

當 15 分鐘以下的延遲、複雜轉換或多組織案例在範圍中時,請評估「平台事件」、「串流 API」或 MuleSoft 作為互補或替代方法。

Yugandhar Bora 是 Salesforce 的軟體工程結構設計師,專門在「資料與情報應用程式」平台內進行資料結構。他負責企業結構檢閱委員會 (EARB) 專注於資料管理和統一資料模型的計畫,同時為自動平台佈建解決方案做出貢獻。