--- schema_version: "1" id: 7c8564a328d1a77f59a665ceaea5f8b42827591da476937c068ddd368456c083 title: Data 360 佈建 collection: architect version: next locale: zh-tw portal_url: https://docs.salesforce.com/architect/next/zh-tw/decision-guides/guides/data-360-provisioning.md canonical_url: https://staging.architect.salesforce.com/docs/architect/zh-tw/decision-guides/guide/data-360-provisioning.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: ad7a0e99cc26f68222dd2d72a11bd401090de59bd006ca5c1e6cdf00afd91e23 products: - 決策指南 - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- ## 概觀 Salesforce Data 360 是以 Hyperforce 為基礎建立的資料平台,可將 Salesforce 和外部資料統一為每個客戶或帳戶的全方位清晰、完整且值得信賴的檢視。由於合併和收購、區域營運、功能性分隔或歷史原因,企業經常經營多個 Salesforce 組織。結構設計師不僅必須決定單一「首頁組織」與多組織組態之間,還必須決定是否要佈建多個獨立 Data 360 例項、使用 Data Cloud One 統一單一例項下的組織,或使用 Data 360 之間的資料共用 (Data 360 至 Data 360 資料共用) 協同合作獨立 Data 360 例項之間。這些選擇會影響監管、合規性、成本、延遲,以及組織調整 AI 和跨組織平台功能的能力。 Data 360 會在收到 Data 360 授權的任何生產組織上自動佈建。Data Cloud One 是 Salesforce 的多組織連線結構,允許單一「首頁組織」主控 Data 360 例項,而其他 Salesforce 組織連線為「伴侶組織」。選擇哪個組織擁有 Data 360 授權,進而成為 Data 360 首頁組織,是具有長期後果的關鍵結構性決定。您佈建 Salesforce Data 360 的方式是一個基本的結構決策,因為這會決定企業如何統一客戶資料、強制執行管治,並在整個組織中啟用關鍵平台功能,特別是 AI、Agentforce 和分析。將組織叢集固定至單一 Data 360 可提供統一的資料模型、集中管理和企業範圍 AI 整備,同時讓「伴侶組織」能夠存取共用中繼資料與功能,如同資料在本機一樣。相反地,當法規、規範或自治需求阻止集中化時,多個獨立 Data 360 例項適合,而 Data 360 組織之間的「資料共用」可在這些例項之間啟用選擇性、零複製協同合作。針對結構設計師,此決策十分重要。它會定義控制資料管理的人員、資料所在位置、平台功能的啟用方式,以及未來整合和 AI 倡議如何順利擴展。即使是目前沒有 Data 360 的組織,透過開發策略來在未來新增 Data 360 存取權,來為您的結構進行未來的驗證也十分重要。Salesforce 在 Sales、Service、Marketing、Commerce、Industry 和 Agentforce 之間的功能會越來越以 Data 360 為基礎。想要使用這些平台功能的組織必須佈建自己的 Data 360,或連線至共用的 Data 360 作為伴隨組織。此指南可協助結構設計師設計佈建策略,以平衡簡單性、企業範圍的一致性、合規性與可擴展性,確保組織可以自信地為 Customer 360、AI 和跨平台創新運用 Data 360。這可協助您決定如何選取要佈建 Data 360 的組織,以及如何在 Data 360 組織之間選擇 Data Cloud One 和 Data 360 組織之間的資料共用,協助您奠定堅實的基礎,將業務推向以 Data 360 為中心的未來。 --- ## 佈建考量事項每個佈建選項 (無論是選擇 Data Cloud One 和 Data 360 組織之間的資料共用,或是將哪個組織指定為「首頁組織」) 都應根據下列跨部門考量事項進行評估:

考量事項	重要原因	範例案例
資料落地與合規性	決定儲存與處理資料的位置。法規規則可能需要特定的區域或多個例項。	一個全球銀行在位於法蘭克福的 Salesforce 組織上提供 Data 360 租戶,以達成 GDPR 規範,並在維吉尼亞州的組織上為其美國部門提供另一個租戶。
管治與安全性	誰擁有及管理 Data 360?保單是否應集中管理,或由每個業務單位委派?	具有強大中央 IT 的跨國公司建立由傑出中心管理的專屬「居家組織」。
自動與集中化	不同的主管可能想要資料的個別擁有權。自動化偏好多個 Data 360;集中化偏好 Data Cloud One。	具有獨立子公司的控股公司可讓每個 BU 執行自己的 Data 360。
延遲與效能	影響查詢速度與體驗,特別是跨區域連線至 Data 360 租戶的「伴隨組織」。	倫敦的銷售小組查詢來自美國 Data 360 租戶的資料可能會看到較高的延遲。
整合複雜性	更多 Data 360 租戶 = 更多管道、API 和中介軟體。合併可簡化整合。	經銷商透過合併至 Data Cloud One 組態,避免建立 10 個 ETL 管道。
零複製資料來源區域	Zero Copy 連接器可能具有跨區域存取需求,可限制 Data 360 可位於哪個區域。	一家公司在 AWS eu-west-1 區域中有 Snowflake 例項。他們可以使用「零複製」將資料聯結至其區域中的 Data 360,但無法使用「零複製」聯結至美國區域中的 Data 360。
私人連線跨區域相容性	在某些情況下,私人連線支援取決於資料來源是否位於與 Data 360 租戶相同的區域。	一家公司在其想要透過零複本連線的 aws-east-1 區域中擁有 Snowflake 例項。只有在 Data 360 首頁組織位於相同區域時,他們才能建立「私人連線」網路連線。
成本與授權	每個 Data 360 租戶都會增加成本。合併至較少的例項可最佳化支出。	醫療照護提供者透過採用 Data Cloud One 而非多個獨立 Data 360 例項來減少授權成本。
未來延展性	今天佈建的選擇為成長奠定基礎。	SaaS 公司從單一 Data 360 例項開始,但計畫在購買 Salesforce 組織的子公司時擴展至 Data Cloud One。
企業範圍 AI 整備	AI 功能和 Agentforce 在每個組織中都需要連線的 Data 360 租戶。佈建決策會影響 AI 模型在整個企業中訓練和啟用的方式。	一家金融服務公司在 Data Cloud One 中統一資料,讓其 Einstein AI 模型能夠存取企業範圍的客戶資料。

### 重要考量事項

佈建與授權繫結:Data 360 會佈建在購買 Data 360 授權的組織中,且區域是由佈建時該組織的位置所決定。
計畫 Data 360 讓您的選項保持開放,即使您現在不需要它也是如此。如果您稍後將 Data 360 實作以支援如 Agentforce 等平台功能,您現在所做的決定可讓您的路徑順利進行。
單一組織客戶:在現有生產組織中佈建 Data 360,以獲得最快的價值轉換時間。
多組織客戶:透過建立最少數量的 Data 360 例項來將複雜性降到最低,理想情況下是使用 Data Cloud One 組態。
多個 Data 360 例項應僅在合規性、落地或組織自主性的需求時使用。在這些情況下,請使用 Data 360 組織之間的資料共用來啟用安全協同合作。
零複製資料來源:請特別注意各種公用雲端和零複製資料來源支援的區域。此外,請判斷安全性狀態是否需要「私人連線」才能連線至這些資料來源,以及是否支援區域內或跨區域連線。
管治與自主性是核心概念:決定要集中管理 Data 360 (傑出中心模型),還是個別的業務行是否需要個別管理的 Data 360 例項。

--- ## 區段 1:佈建 Data 360 – 選擇主要組織 ### 1.1 什麼是 Data 360 首頁組織? 當您購買 Data 360 授權時,Data 360 例項會佈建在與該授權相關聯的 Salesforce 組織中。此組織稱為 Data 360 首頁組織。顯示 Data 360 首頁組織的決策圖

「首頁組織」是您 Data 360 例項的安克圖。這是下列位置: - 系統會管理 Data 360 儲存和計算 (在佈建時選取的區域中)。 - 套用管理、管治和安全性原則。 - 系統會執行資料取用、調和、身分解析、區隔和啟用。在多組織案例中,首頁組織會管理其他 Salesforce「伴侶」組織的中心 Data 360 例項。首頁組織為何重要: - 它會決定 Data 360 例項的地理位置。 - 它會決定擁有與管理 Data 360 例項的人員。「Data 360 首頁組織」中的管理員可以存取在「Data 360」中採取的所有資料。 - 它會控制 Data Cloud One 組態中的「伴隨組織」連線。 - 這會為您的企業資料策略奠定基礎,稍後變更會很困難且具有破壞性。 ### 1.2 決策:現有組織或新組織作為主要組織? 第一個重大決定是要在現有生產組織中佈建 Data 360 還是建立新的專屬組織作為「首頁組織」。將現有組織與新組織顯示為主要組織的決策圖

#### 選項 A:在現有組織中佈建 Data 360 **最適用於:**具有單一 Salesforce 組織的客戶,或已擁有大多數業務執行所在主要集中組織的多組織客戶。顯示現有組織中 Data 360 佈建的圖表

- **優點**: - 最簡單的路徑:Data 360 會佈建在 CRM 資料已存在的位置。 - 立即存取本機「銷售」、「服務」和「行銷」資料。 - 不需要額外的整合。 - 管理的授權與環境愈少。 - 加速提早採用、試用版和生產使用個案。 - **缺點**: - 可繼承現有組織的監管或技術債務。 - 如果沒有單一「主要組織」,則選取一個「主要組織」可能會產生擁有權討論。 - 與組織位置繫結的績效;可能與企業範圍的落地需求不相符。 - 如果多個業務單位使用不同的組織,如果未與 Data Cloud One 配對,則本機佈建可能會導致分割。 **範例:** 具有一個 Salesforce 組織的 SaaS 公司會在該組織中佈建 Data 360,以統一客戶訂閱與支援資料。 #### 選項 B:在新的專用組織中佈建 Data 360 **最適用於:**擁有多個 Salesforce 組織且無法符合單一主要組織的客戶,或擁有強大「傑出中心」(CoE) 模式的企業。顯示新專屬組織中 Data 360 佈建的圖表

- **優點**: - 管理的清除圖表,沒有繼承的組織複雜性。 - 集中控制多個行業。 - 根據合規性需求彈性選擇區域。 - 作為中立的「共用服務」組織,不與一個業務單位繫結。 - 針對未來 Data Cloud One 結構進行設定 (具有多個伴侶組織的「居家組織」)。 - **缺點**: - 客戶必須授權新的 Salesforce 組織來佈建 Data 360。 - 透過 Data Cloud One 伴隨連線將組織連線至 Data 360 所需的其他整合。 - 可新增管理負擔 (使用者管理、安全性、身分)。 - 與現有生產組織中的佈建相比,時間轉換值的速度較慢。 **範例:** 一個跨國金融服務公司建立一個專屬的「首頁組織」來佈建 Data 360。所有業務單位組織 (零售、財富、商業銀行業務) 透過 Data Cloud One 連線為「伴侶組織」。 #### 決策條件

考量事項	現有組織作為首頁組織 (偏好預設值)	將新組織作為首頁組織 (替代)
簡化	建立於現有使用者和資料結構以加速設定;Data 360 預設會與「首頁組織」整合。	需要授權和設定新的 Salesforce 組織,以及額外的管理負擔。
時間對價值	立即使用本機 CRM 資料。	延遲 ramp;需要整合。
管治	繼承現有組織的基本管理模式 - 現有使用者和權限集。如果組織已是中心,則可能可以這麼做。	清除管治狀況;適用於 CoE 主導的模型。
合規性	與現有組織區域繫結的住所。	選取與現有組織無關區域的彈性。
效能	本機 CRM 查詢的最佳效能。	取決於「伴隨組織」的連線,無論是與其他組織的相同區域或跨區域。
未來延展性	如果與 Data Cloud One 配對,則運作良好;如果選擇錯誤的組織,則較難稍後進行排班。	使用 Data Cloud One 輕鬆調整規模;設計以保持中立性。
成本	增量成本降低。	來自其他環境的高額負擔率。

### 1.3 建議一般原則是,建議使用現有的主要組織作為您的「首頁組織」,以儘量減少初始工作並加速採用。只有在您的長期管理或合規策略需要時,才能建立新的專屬首頁組織。針對擁有「傑出中心」(COE) 的大型企業,建立新的專屬「首頁組織」是常見的選擇。 **單一組織環境** 在您現有的生產組織中佈建 Data 360。這可最大化簡易性和立即值。這可避免不必要的整合負擔。 **多個組織環境** 您可以選擇其中一個主要組織 (通常是您大多數業務執行所在的組織,或已作為集中式 CRM 的組織),以作為「首頁組織」。這可減少複雜性、最小化設定工作,並讓您快速實現 Data 360 的價值。使用現有的主要組織也會避免管理新環境的成本和整合工作。 **何時考慮新的專用居家組織** 如果您的組織擁有強大的傑出中心 (CoE),且想要與業務單位組織分開管理。如果由於合規性或組織限制,沒有單一現有組織適合。在這些情況下,建立新的「首頁組織」可提供彈性和中立性,但時間轉換價值會變慢。 --- ## 區段 2:多組織策略與 Data Cloud One ### 2.1 多組織挑戰企業經常營運多個 Salesforce 組織,這不是極端個案,而是規則。截至 2024 年 2 月,約 19,000 位 Salesforce 客戶已執行一個以上的 Salesforce 組織。為什麼會發生此情況? - **併購和併購:**新收購的公司有自己的 Salesforce 例項。 - **區域作業:**針對歐盟、北美洲、亞太區等個別組織,通常可滿足資料落地法律。 - **功能分隔:**不同的業務單位 (例如 Retail Banking、Wealth Management、Insurance) 會維持自己的組織以保持自主性。 - **法規或安全性隔離:**基於合規性原因,某些產業必須以邏輯方式建立不同的組織。 - **歷史/技術原因:**隨著時間的推移,客戶會自然累積多個組織。每個原因都個別有意義,但一起建立資料的分割。若沒有統一層,每個組織只會有客戶的部分檢視。架構挑戰:如何將跨組織的資料統一為單一事實來源,同時遵循合規性、管治與自主性需求? --- ### 2.2 什麼是 Data Cloud One? Data Cloud One 是 Salesforce 的多組織連線結構,允許多個 Salesforce 組織共用單一 Data 360 例項。這是具有多個 Salesforce 組織的企業建議模式。在任何 Data Cloud One 叢集中,將一個 Salesforce 組織指定為「主要組織」,主控 Data 360 例項。其他 Salesforce 組織會以「伴侶組織」形式連線,從「首頁組織」的 Data 360 中取用統一的資料和中繼資料。顯示 Data Cloud One 結構的圖表

#### Data Cloud One 的運作方式

資料獲取與統一 (主要組織)
- 系統只會從「首頁組織」進行所有資料取用組態 (Salesforce CRM、外部來源、串流、批次)。
- 與「首頁組織」繫結的 Data 360 租戶會執行身分解析、調和、建模和統一至信任的 Customer 360 設定檔。
- Data 360 管理、管治原則、標記和遮蔽會從「首頁組織」集中套用。
資料空間結構
- 從「首頁組織」中,資料會組織為「資料空間」,這會作為資料、中繼資料和程序的邏輯容器。
- 企業可以為品牌、區域或業務線路建立「資料空間」。
- 資料空間共用:從「首頁組織」中,特定「資料空間」會選擇性與「伴侶組織」共用。這可確保只有相關資料 (以及相關聯的中繼資料) 會流至正確的組織。
中繼資料共用
「伴侶組織」會從「首頁組織」接收中繼資料定義,包括資料模型物件 (DMO)、統一設定檔結構描述、已計算洞察、區段等。這些項目原生顯示在「伴侶組織」內,就如同是本機資產,但實際上會連結至「首頁組織」。
要在「居家組織」中執行的工作與工作伴侶組織

能力	住家組織	伴侶組織
「連線」設定連接器、建立資料串流,或將資料採取或聯合	✅	❌
協調與統一建立並執行資料轉換和身分解析	✅	❌
使用資料空間和權限來保護資料的安全管理	✅	✅
區段與預估建立區段、洞察和 Einstein Studio 模型	✅	✅
啟用隨處的啟用、資料動作	✅	✅
平台功能提示詞產生器、流程、報告、增強等	✅	✅
Data 360 增強功能 Prospecting Center、Sales 和 Service Cloud 功能、Agentforce 等	✅	✅

平台功能比對
從使用者和產生者的角度來看,一旦共用中繼資料,首頁與伴侶組織在使用 Salesforce 平台功能方面有一些功能差異。支援的功能清單可在「伴侶組織」的 Data 360 功能中找到。
- 當中繼資料可用時,Salesforce Platform 功能 (例如流程、報告、提示詞產生器、顯示面板和其他平台原生工具) 會同時在「首頁」與「伴隨組織」中運作。
- Data 360 技術支援的功能 (例如 Agentforce、Prospecting Center、Sales Cloud Einstein 功能和 Service Cloud AI 功能) 也可在「首頁」與「伴侶組織」中順暢運作。某些功能可能正在達到完整相容性的路徑,但整體目標是針對依賴 Data 360 的所有跨雲端功能,讓「首頁」與「伴侶」組織的功能相同。
消耗模型
所有「伴侶組織」活動 (查詢、區段執行、Data 360 觸發流程、AI 用量、Einstein Trust 層記錄等) 都會從「首頁組織」中耗用 Data 360 點數。耗用流程只有一種方式:系統會集中化、計費和根據「居家組織」的信用分配追蹤信用額。不過,您可以逐層細分以查看每個個別組織在 Digital Wallet 中使用的信用額。
設計原則:水平建構
Data Cloud One 設計為 Salesforce 平台的水平建構,類似於 Sandbox。目標是讓 Salesforce 發行中的每個新功能都能在「首頁」與「伴侶組織」中運作,而無需額外設定。這可確保 Data Cloud One 不僅是資料結構的選擇,也是未來的 Salesforce 平台基礎元素。

--- ### 2.3 決策:多個獨立 Data 360 與一個共用 Data 360 (Data Cloud One) 具有多個組織的企業必須選擇 Data 360 在其生態系統中的位置和方式。他們想要在每個組織中佈建獨立 Data 360,還是使用 Data Cloud One 在單一「首頁組織」之下統一組織? #### 選項 A:多個獨立 Data 360 每個 Salesforce 組織都會佈建自己的 Data 360 例項。 **優點**: - **自治**:每個業務單位或區域都控制自己的 Data 360。 - 每個組織中的 **簡化**:管理、安全性和自訂項目已本地化。 - **法規合規性**:當需要嚴格的法規分隔時很實用 (例如,資料不能跨境)。 **缺點**: - **資料孤島:**Customer 360 無法跨組織達成。 - **成本愈高**:每個例項都需要授權、管理與整合。客戶最終會多次採取相同的來源資料,以在多個不同的組織中達成完整的 C360 檢視。 - **重複工作:**必須在每個 Data 360 中重複身分解析、區隔和增強。 #### 選項 B:一個共用 Data 360 (Data Cloud One 叢集) 單一 Data 360 會佈建在「首頁組織」,其他的 Salesforce 組織會連線為「伴侶組織」。 **優點**: - **單一事實來源 (SSOT):**所有組織皆共用相同的統一資料模型。 - **成本效率:**只需管理一個 Data 360 授權與基礎結構。 - **統一管理:**系統會集中套用原則、安全性和合規性控制。 - **跨組織增強:**「伴侶組織」可以存取協調的設定檔、洞察和區段。 - **AI 整備:**企業範圍資料集可更完善地訓練和啟用 AI 模型。 - **未來證明:**新增「伴隨組織」很簡單,不需要新增 Data 360。 **缺點**: - **其他準備:**需要規劃組織對首頁組織的連線。 - **延遲考量事項:**不同區域中的「伴侶組織」會看見較慢的查詢速度。 - **複雜管理:**如果每個組織的自訂需求都非常不同,則細微的管理可能很複雜。 #### 選項 C:多個 Data Cloud One 叢集在某些情況下,管治、合規性或其他業務需求可能會使將每個組織分組在一起變得不實用。這可能會導致需要實作混合式解決方案,其中企業會營運數個 Data 360,每個項目皆為不同「伴隨組織」叢集的「首頁組織」。 #### 範例: 多國企業擁有多個區域的 Salesforce 組織,包括歐洲、美國和亞洲。為了遵循區域資料落地法規,他們為每個個別區域佈建一個 Data 360。 #### 決策條件

考量事項	多個獨立 Data 360	一個共用 Data 360 (Data Cloud One )
自主	每個組織或業務單位的高自主性。	集中化治理,每個組織的自主權降低。
合規性	當需要嚴格分隔時很實用 (例如,地區法律)。	當落地允許集中化時效果最佳。
成本	授權與管理成本較高。	更具成本效益;多個組織的一個授權。
管治	分割;各組織的原則不同。	組織之間集中的一致原則。
資料集中	每個組織都有自己的檢視;沒有 Enterprise 360。	統一的資料集,無重複。
AI/Analytics	限制為每個組織的資料。	更準確的企業範圍模型。
複雜性	要管理的例項越多,整合越多。	更簡單的結構,更少移動組件。
效能	最適用於組織內使用個案。	「伴侶組織」存取權可能會導致延遲。

--- ### 2.4 建議 **偏好的模式:****Data Cloud One** 預設為具有已連線多組織企業的「伴侶組織」的單一「首頁組織」。這會建立企業範圍 Customer 360、簡化監管並最佳化成本。 **使用多個 Data 360 的時機:** 只有在合規性、居住權或組織自主權嚴格要求時。例如,由於法規,歐洲作業必須與美國作業保持完全分開。 **如何在 Data Cloud One 中選擇「首頁組織」:** 從考量其中一個主要組織開始,通常是大多數業務執行所在的組織。在其中佈建 Data 360 可將複雜性降到最低,並將早期價值最大化。只有在沒有現有組織適合的情況下,請考慮建立由「傑出中心小組」管理的專屬「首頁組織」。 **一般原則:** 在多組織環境中,將 Data 360 的數量降到最低。將 Data Cloud One 作為預設模式,以減少重複項目、啟用 AI 整備並簡化管治。 --- ## 區段 3:Data 360 組織之間的多個 Data 360 與資料共用 ### 3.1 Data 360 組織之間的資料共用為何? 雖然 Data Cloud One 是大多數企業的建議方法,但在某些情況下,客戶可能需要佈建多個 Data 360 例項。一旦有多個 Data 360 存在,其間的統一不會自動發生。 Data 360 到 Data 360 資料共用可讓客戶在 Data 360 例項之間共用特定物件,而無須重複或自訂管道。這是專為跨 Data 360 協同合作所設計的零複製中繼資料共用機制。 #### 運作方式 - 每個 Data 360 都佈建在自己的「首頁組織」中。 - 管理員可以建立資料共用,即他們想要共用的特定物件分組。 - 所選資料的存取權會與目標組織的 Data 360 共用,其中物件會如同在本機定義一樣顯示。基本資料會保留在來源 Data 360 中;只有存取權會共用。 - 標記未共用。僅原始物件可供使用;目標組織必須視需要重新套用任何監管、作業或 AI 標記。 #### 與 Data Cloud One 的主要差異 - 在 Data Cloud One 中,多個「伴侶組織」共用單一 Data 360 例項。平台功能 (Agentforce、Prospecting Center、Tableau Next 等) 都會在相同的基本資料上執行,以確保一致性。 - 在 Data 360 組織之間使用資料共用時,每個組織都有自己的 Data 360。如組織 A 和組織 B 中的 Agentforce 等功能會在其本機例項上獨立作業。不會自動進行共用,必須建立有意的資料共用,才能僅針對特定物件協同合作。 --- ### 3.2 Data 360 組織之間資料共用的使用個案 **區域合規性:** 一個跨國零售商在歐盟提供一個 Data 360,在美國提供另一個 Data 360。Data 360 至 Data 360 資料共用可讓公司彙總洞察 (例如,忠誠度 KPI),以便與美國總部共用,而原始資料仍保留在本機。 **業務單位協同合作:** 集團會針對「零售」和「保險」執行個別的 Data 360。Data 360 之間的資料共用可讓使用者存取單一的權威資料來源,而無須移動或複製。透過 Data 360 組織之間的資料共用,保險組織會收到零售的「高價值客戶」區段,用於鎖定目標的交叉銷售行銷活動。 **併購:** 父系公司取得附屬公司,並擁有自己的 Data 360。有了兩個可管理的例項,保留短期資料孤立可保留資料安全性和 SSOT 完整性。同時,兩個 Data 360 例項之間共用資料,可在轉換期間進行必要的協同合作。 **聯邦執行顯示面板:** 跨大陸的跨國公司會為每個區域佈建個別 Data 360。主管想要聯合的每季績效檢視。每個區域 Data 360 都會與「執行組織」共用彙總的已計算洞察,以啟用企業範圍報告。 #### Data 360 組織之間資料共用的優點與缺點

因素	優點	缺點
資料落地	支援區域分隔,同時啟用協同合作。	不會移除管理多個 Data 360 的需求。
資料重複	複製零;無重複物件。	需要刻意選取要包含在每個資料共用的物件。
管治	共用是明確且有意的 (物件級)。	沒有標記或原則流程;目標組織必須重新套用監管。
複雜性	啟用不集中化的選用協同合作。	需要管理多個 Data 360 和資料共用。
AI/Analytics	可進行區域 AI/分析;洞察可在組織之間共用。	除非有意共用資料,否則不會有企業範圍 AI。
平台功能	每個組織的 Data 360 技術支援的功能會獨立執行。	無自動共用 — 若未經仔細設計,則可能有重複的風險。
成本	可能會減少 ETL 銷售管道的需求。	多個 Data 360 仍會產生成本。耗用資料查詢和資料共用的信用額。

#### 決策條件

考量事項	Data Cloud One (偏好用於多組織)	Data 360 組織之間的資料共用
單一事實來源	✅ 是,所有組織皆共用相同的 DC。	∗ 否—每個 Data 360 都有自己的資料模型。
合規性	僅在落地允許集中化時才適用。	當住所法禁止集中化時為必要。
管治	集中化,一致。	聯合;有意共用物件層級。
複雜性	移動組件愈少,愈簡單。	ore complex — 需要組態資料共用和多個 Data 360。
AI/Analytics	企業範圍 AI 模型。	區域 AI;洞察可選擇性共用。
平台功能	「共用資料 360」表示所有功能在「首頁 + 伴侶」之間一致運作。	功能會在每個 Data 360 中獨立執行;共用必須明確。

### 3.3 最佳作法 **如果您的企業有多個 Data 360:** - 在 Data 360 組織之間使用資料共用來跨組織協同合作,而不是建立自訂銷售管道或重複資料。 - 透過建立「資料共用」,並將其授與目標組織來共用特定物件 (DMO、已計算洞察、區段)。 - 請注意,標記未共用—接收組織必須重新套用標記 (例如,監管、分類、AI 增強)。 **使用 Data 360 組織之間的資料共用時機:** - 符合防止集中化的法規需求。 - 維護業務單位自主性,同時啟用選擇性協同合作。 - 提供跨多個區域的聯合主管顯示面板。 - 橋接無法立即合併的 M&A 案例。 **小心設計** 共用必須是刻意且物件特定的。避免過度共用—讓「資料共用」符合業務與合規需求。將 Data 360 至 Data 360 資料共用視為同盟策略,而不是取代 Data Cloud One。 --- ## 摘要

每個組織都應規劃存取 Data 360
- 在未來,所有 Salesforce 平台功能 (從 Sales Cloud 和 Service Cloud 到 Agentforce) 都需要 Data 360 連線。每個組織都必須主控 Data 360 首頁組織,或是透過 Data Cloud One 連線的「伴隨組織」。
思考企業範圍,而不是逐個組織
- 避免單獨進行單一的業務線決策。
- 佈建應由共同決定,理想情況下由企業結構或資料管理委員會決定。一律預期未來 AI 和分析需求,這取決於廣泛且統一的資料集。
最小化資料孤立
- 在現有主要組織中佈建 Data 360 以獲得簡單且快速的功能。
- 在多組織環境中,Data Cloud One 是統一 Data 360 組織的預設模式。
- 僅在合規性、落地或組織自主性嚴格必要時,才能佈建多個 Data 360。
如果您必須執行多個 Data 360,請刻意設計
- 設定 Data 360 組織之間的資料共用以協同合作,而非自訂 ETL 銷售管道。
- 透過資料共用共用特定物件 (DMO、已計算洞察、區段)。
- 請記住:不會共用標記,而耗用量會向來源組織計費。
提前計畫管理與擁有權
- 決定要集中管理 Data 360 (傑出中心模式) 還是委派給業務行。定義管理員、安全性小組和合規性商機的角色。
- 避免不明確:擁有權不明確是常見的摩擦來源。
避免短期快速鍵
- 不要在沒有長期計畫的情況下針對 POC 開發多個 Data 360,這會在稍後建立中斷式的合併工作。
- 請改為將試用版與早期部署與您的企業範圍佈建策略保持一致。

這些佈建選擇十分重要,因為 Salesforce 平台正在發展為 Data 360 First 模型,其中從客戶區隔到 AI 工作人員奠基的每個功能都將依賴此模型。您今天採取的決策將為企業統一客戶資料的效率、您可以快速採用新 Salesforce 功能,以及您如何確信在整個業務中擴充 AI 的基礎。若要成功,您必須謹慎佈建、儘量減少重複項目、符合合規性需求、刻意管理,並思考長期。最終,佈建 Data 360 是將資料、AI 和 CRM 作為一個凝聚式平台一起運作的第一步。 # ## 關於作者 Kunal Goyal 是 Salesforce 的產品管理部門主管,專注於進階化 Data 360 中的多組織結構和延展性。自 2017 年起,他負責多個專注於跨組織協同合作和多租戶系統設計的計畫和產品。Kunal 是 Data 360 最佳作法結構商機之一,也是 Data Cloud One、設定、佈建和管理員體驗的產品擁有者。 Erin Wagner Tidwell 是 Data 360 的主要技術作者和內容設計師。她從 2013 年開始在 Salesforce 工作。她致力於透過清楚、一致且準確的技術文件和應用程式內通訊,讓 Data 360 更容易理解和使用。 Yugandhar Bora 是 Salesforce 的「軟體工程結構設計師」,專門在「資料與情報應用程式」平台內進行資料結構。他負責領導企業結構審查委員會 (EARB) 計畫,專注於資料管理和統一資料模型,同時為自動平台佈建解決方案做出貢獻。 Samarpan Jain 是 Salesforce 的首席結構設計師,專門處理 Commerce Cloud、平台整合和跨組織結構。他是 Salesforce 最長期的員工之一,負責主要計畫,包括政府客戶的資料落地合規性與 Data 360 用量歸屬系統。