--- schema_version: "1" id: 6eee3d3282ec5a72b84c44e00a07e7b0cfad0aba08246844727a1cc30608b1ec title: Data 360 佈建 collection: architect version: current locale: zh-tw portal_url: https://docs.salesforce.com/architect/current/zh-tw/decision-guides/guides/data-360-provisioning.md canonical_url: https://architect.salesforce.com/docs/architect/zh-tw/decision-guides/guide/data-360-provisioning.html source_site: architect.salesforce.com content_type: documentation content_hash: 7689695c41b2a115aa35bc4d093745ca32d9e66731b781ef8ec53a3b6c554018 products: - 決策指南 - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- # Data 360 佈建 Salesforce Data 360 是以 [Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/) 為基礎建立的資料平台,可將 Salesforce 和外部資料整合為每個客戶或帳戶的清晰、完整且值得信賴的全方位檢視。 由於合併和收購、區域營運、功能性分隔或歷史原因,企業經常經營多個 Salesforce 組織。結構設計師可針對 Data 360 進行數項決策,這些都會影響管理、合規性、成本、延遲,以及組織調整 AI 和跨組織平台功能的能力。 ## 指南概觀 本指南提供使用 Data 360 進行佈建決策的架構。這些決策包括: - 選取單一首頁組織與多組織組態 - 佈建多個獨立 Data 360 例項 - 使用 Data Cloud One 在單一例項下統一組織 - 在使用 Data 360 組織之間資料共用的獨立 Data 360 例項之間協同合作 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 存取權來為其架構進行未來的測試也十分重要。Sales、Service、Marketing、Commerce、Industry 和 Agentforce 的 Salesforce 功能逐漸以 Data 360 為基礎。想要使用這些平台功能的組織必須佈建自己的 Data 360 或連線至共用的 Data 360 作為伴侶組織。 此指南可協助結構設計師設計佈建策略,以平衡簡單性、企業範圍的一致性、合規性和延展性,確保組織可以自信地利用 Data 360 for Customer 360、AI 和跨平台創新。使用此指南判斷哪些組織需要 Data 360,以及是否使用 Data Cloud One 或 Data 360 組織之間的資料共用。此策略為以 Data 360 為中心的未來建立堅實的基礎。 ## 範疇中的產品
Salesforce Platform 標誌 Salesforce Data 360 是 Salesforce 的即時超大規模資料平台,可將來自任何來源 (CRM、網頁、行動或外部資料湖) 的資料協調並統一至可運作的單一客戶設定檔。作為 Customer 360 平台的重要元件,其可強化銷售、服務和行銷的 AI、分析和個人化體驗。
## 接待時間 - **每個組織都應規劃存取 Data 360 例項。**每個組織都必須主控 Data 360 首頁組織,或是透過 Data Cloud One 連線的伴侶組織。 - **思考企業範圍,而不是逐個組織。**避免單獨進行單一的業務線決策。理想情況下,企業結構或資料管理委員會應共同決定佈建策略。一律預期未來 AI 和分析需求,這取決於廣泛且統一的資料集。 - **及早計畫監管與擁有權。**決定要集中管理 Data 360 (傑出中心模式) 還是委派給業務行。定義管理員、安全性小組和合規性商機的角色。避免有不明確的擁有權,因為擁有權不明確可能會造成問題。 - **請記住,佈建與授權相關聯。**購買 Data 360 授權的組織會決定 Data 360 佈建的位置,而該組織的位置會決定區域。 - **瞭解資料來源支援的考量事項。**請特別注意各種公用雲端和零複製資料來源支援的區域。此外,請判斷安全性狀態是否需要「私人連線」才能連線至這些資料來源,以及是否支援區域內或跨區域連線。 - **根據單一組織或多個組織來佈建。**針對單一組織的客戶,請在現有生產組織中佈建 Data 360,以獲得最快的價值轉換時間。針對多組織客戶,請盡可能建立最少數量的 Data 360 例項,最好是使用 Data Cloud One 組態,以將複雜性降到最低。 - **僅在必要時使用** **多個 Data 360 例項。**多個例項僅在合規性、居住權或組織自主權要求時使用。在這些情況下,請使用 Data 360 組織之間的 [資料共用](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5)來啟用安全的協同合作。 - **設定 Data 360 組織之間的資料共用以進行協同合作,而非針對自訂 ETL 銷售管道。**透過資料共用共用特定物件 (DMO、已計算洞察、區段)。請記住,系統不會共用標記,而耗用量會計入來源組織。 - **避免短期快速鍵。**若沒有長期計畫,請勿執行多個 Data 360 組織的概念證明 (POC)。讓試用版與早期部署符合您企業範圍佈建策略。 ## 決策點 根據這些跨部門考量事項,評估每個佈建選項 (在 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 管道。
零複製資料來源區域 某些連接器的跨區域存取需求可能會限制 Data 360 組織的區域或位置。 一家公司在 AWS eu-west-1 區域中有 Snowflake 例項。他們可以使用「零複製」將資料聯結至其區域中的 Data 360,但無法使用「零複製」聯結至美國區域中的 Data 360。
私人連線跨區域相容性 「私人連線」支援有時取決於資料來源是否位於與 Data 360 租戶相同的區域。 一家公司在 aws-east-1 區域中有 Snowflake 例項,他們想要透過零複製將其連線至 Data 360。只有在 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 例項會佈建在與該授權相關聯的 Salesforce 組織中。此組織稱為 Data 360 首頁組織。首頁組織是 Data 360 例項的安卡。這包括: - Data 360 儲存空間與計算的管理 (在佈建時選取的區域中)。 - 套用管理、管治與安全性原則 - 資料取用、調和、身分解析、區隔和啟用的效能 在多組織案例中,主要組織會管理其他 Salesforce「伴侶」組織的中心 Data 360 例項。 **首頁組織:** - 決定 Data 360 例項的地理位置。 - 決定擁有與管理 Data 360 例項的人員。您 Data 360 首頁組織中的管理員可以存取在 Data 360 中取用的所有資料。 - 控制 Data Cloud One 組態中的伴侶組織連線。 - 設定您企業資料策略的基礎,稍後變更會很困難且具有破壞性。 如需有關 Data 360 首頁組織的詳細資訊,請參閱 [Data 360 整合模式與作法](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices)。 #### 決策:現有組織或新組織作為主要組織? 第一個重大決定是要在現有生產組織中佈建 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 資料 需要慢速的延展和整合。
監管 繼承現有組織的基本管理模式—現有使用者和權限集 (如果組織已為中心,則可以接受)。 清除監管狀況。適用於 COE 導向的模型。
合規性 與現有組織區域繫結的住所 選取與現有組織無關區域的彈性
績效 本機 CRM 查詢的最佳效能 取決於伴侶組織的連線能力,無論是與其他組織的相同區域或跨區域
未來延展性 與 Data Cloud One 配對時運作良好。如果選擇錯誤的組織,稍後更難進行排班 使用 Data Cloud One 輕鬆調整規模。為了保持中立性而設計。
成本 增量成本降低 來自其他環境的高額負擔
#### 建議 一般原則是,使用現有的主要組織作為您的主要組織,以儘量減少初始工作並加速採用。只有在您的長期管理或合規策略需要時,才能建立新的專屬首頁組織。針對擁有「傑出中心」(COE) 的大型企業,建立新的專屬總部組織是常見的選擇。 **單一組織環境** 在您現有的生產組織中佈建 Data 360。這可最大化簡易性和立即值。這可避免不必要的整合負擔。 **多個組織環境** 您可以選擇其中一個主要組織 (通常是您大多數業務執行所在的組織,或作為集中式 CRM 的組織) 作為主組織。這可減少複雜性、最小化設定工作,並讓您快速實現 Data 360 的價值。使用現有的主要組織也會避免管理新環境的成本和整合工作。 **何時考慮新的專用居家組織** 建立總部組織可提供彈性和中立性,但在這些情況下,時間轉換價值會變慢。 - 如果您的組織擁有強大的傑出中心 (CoE),且想要與業務單位組織分開管理。 - 如果由於合規性或組織限制,沒有單一現有組織適合。 ### 套用多組織策略 #### 多組織挑戰 企業通常會經營多個 Salesforce 組織,這不是極端個案,而是規則。截至 2024 年 2 月,約 19,000 位 Salesforce 客戶已執行一個以上的 Salesforce 組織。 為什麼會發生此情況? - **併購和併購:**新收購的公司有自己的 Salesforce 例項。 - **區域作業:**針對歐盟、北美洲、亞太區等個別組織,通常可滿足資料落地法律。 - **功能分隔:**不同的業務單位 (例如 Retail Banking、Wealth Management、Insurance) 保留自己的組織以保持自主性。 - **法規或安全性隔離:**基於合規性原因,某些產業必須以邏輯方式建立不同的組織。 - **歷史或技術原因:**隨著時間的推移,客戶會自然累積多個組織。 每個原因都個別有意義,但一起建立資料的分割。若沒有統一層,每個組織只會有客戶的部分檢視。 架構挑戰:如何將跨組織的資料統一為單一事實來源,同時遵循合規性、管治與自主性需求? --- #### 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 的運作方式** - **Data Capture and Unification (主要組織)** - 系統只會從主要組織進行所有資料取用組態 (Salesforce CRM、外部來源、串流、批次)。 - 繫結至主要組織的 Data 360 租戶可執行身分解析、調和、建模和統一至信任的客戶設定檔。 - Data 360 管理、管治原則、標記和遮蔽會從主要組織集中套用。 - **資料空間結構** - 從主要組織中,資料會組織成資料空間,這些空間會作為資料、中繼資料和程序的邏輯容器。 - 企業可以為品牌、區域或業務線路建立資料空間。 - 資料空間共用:從主要組織中,特定資料空間會選擇性與伴隨組織共用。這可確保只有相關資料 (以及相關聯的中繼資料) 會流至正確的組織。 - **中繼資料共用** 伴隨組織會從主要組織接收中繼資料定義,包括資料模型物件 (DMO)、統一設定檔結構描述、已計算洞察、區段[等](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)。這些項目原生顯示在伴隨組織內,就如同是本機資產,但會連結至主要組織。 - **首頁組織與伴侶組織的功能** 首頁與伴隨組織的功能存取權不同。伴隨組織無法採取或統一資料,且依賴主要組織來採取、建模和統一。伴侶組織可以存取 Data 360 資料,以增強 Data 360 技術提供的平台功能,並可在共用的信任資料上建立本機洞察、區段和流程。在未來願景中,他們也可以存取啟用功能。
能力 住家組織 伴侶組織
「連線」 「設定連接器」、「建立資料串流」、「取用或聯合資料」權限 ✅ ❌
協調和統一建立並執行資料轉換和身分解析 ✅ ❌
使用資料空間與權限管理安全資料 ✅ ✅
建立區段、洞察和建立 Einstein Studio 模型 ✅ ✅
「啟用隨處」啟用、資料動作 ✅ ✅
平台功能:提示詞產生器、流程、報告、增強 [等] (https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Data 360 技術支援的功能:Prospecting Center、Sales 和 Service Cloud 功能、Agentforce 等 ✅ ✅
- **平台功能比對** 從使用者和產生者的角度來看,一旦共用中繼資料,首頁與伴侶組織在使用 Salesforce 平台功能方面會有一些功能差異。支援的功能清單可在「伴隨者組織」的 [Data 360 功能](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) 中找到。 - 當中繼資料可用時,Salesforce Platform 功能 (例如流程、報告、提示詞產生器、顯示面板和其他平台原生工具) 會同時在首頁與伴侶組織中運作。 - Data 360 技術支援的功能 (例如 Agentforce、Prospecting Center、Sales Cloud Einstein 功能和 Service Cloud AI 功能) 也可在首頁與伴侶組織中順暢運作。某些功能可能正在達到完整相容性的路徑,但整體目標是針對依賴 Data 360 的所有跨雲端功能,讓首頁與伴隨者組織的功能相同。 - **消耗模型** 所有伴侶組織活動 (查詢、區段執行、Data 360 觸發流程、AI 用量、Einstein Trust Layer 記錄等) 都會從主組織中耗用 Data 360 點數。耗用流程只有一種方式:系統會集中化、計費並根據主要組織的信用分配追蹤信用額。不過,您可以逐層細分以查看每個個別組織在 Digital Wallet 中使用的信用額。 - **設計原則:水平建構** Data 360 中的水平建構是基本設計原則,主要透過 Data Cloud One 實作,允許單一 Data Cloud 例項跨多個不同的 Salesforce CRM 組織。目標是讓每個新的發行功能都能在首頁與伴隨組織中運作,而無須進行額外設定。此功能可確保 Data Cloud One 不是資料結構的選擇,而是未來的 Salesforce 平台基礎元素。 --- #### 決策:多個資料組織與共用 Data 360 (Data Cloud One) 具有多個組織的企業必須選擇 Data 360 在其生態系統中的位置和方式。他們想要在每個組織中佈建獨立的 Data 360 組織,還是使用 Data Cloud One 在單一首頁組織之下統一組織? **選項 A:多個獨立 Data 360 組織** 每個 Salesforce 組織都會佈建自己的 Data 360 例項。 **優點:** - **自發:**每個業務單位或區域都控制自己的 Data 360。 - **每個組織中的簡化:**管理、安全性和自訂項目已本地化。 - **法規合規性:**當需要嚴格的法規分隔時很實用 (例如,資料不能跨境)。 **選項:** - **資料孤島:**統一設定檔無法在組織之間達成。 - **成本較高:**每個例項都需要授權、管理與整合。客戶最終會在多個不同組織之間多次採取相同的來源資料。 - **重複工作:**必須在每個 Data 360 例項中重複身分解析、區隔和增強。 **選項 B:一個共用 Data 360 (Data Cloud One 叢集)** 單一 Data 360 會佈建在主組織中,其他的 Salesforce 組織會連線為伴侶組織。 **優點:** - **單一事實來源 (SSOT):**所有組織皆共用統一的資料模型。 - **成本效率:**僅管理一個 Data 360 授權與基礎結構。 - **統一管理:**集中套用的原則、安全性和規範控制。 - **跨組織增強:**存取伴隨組織之間的協調設定檔、洞察和區段。 - **AI 整備:**企業範圍資料集可讓 AI 模型獲得更好的訓練和啟用。 - **未來證明:**新增伴侶組織很簡單,因為不需要新的 Data 360 組織。 **選項:** - **其他準備:**One Data 360 需要規劃組織對首頁組織的連線。 - **延遲考量事項:**不同區域的同伴組織可看見較慢的查詢速度。 - **複雜管理:**如果每個組織有不同的自訂需求,則細微管理可能很複雜。 **選項 C:多個 Data Cloud One 叢集** **有時**,管治、合規或其他業務需求可能會使將每個組織分組在一起變得不實用。這可能會導致需要實作混合式解決方案,其中企業會營運數個 Data 360 組織,每個組織皆為不同的同伴組織叢集的主要組織。 **範例:** 一個跨國公司擁有多個區域的 Salesforce 組織,包括歐洲、美國和亞洲。為了遵循區域資料落地法規,他們為每個個別區域佈建一個 Data 360。 **決策條件**
考量事項 多個獨立 Data 360 組織 一個共用 Data 360 (Data Cloud One)
自治 每個組織或業務單位的高自主性 集中管理,每個組織的自主權降低
合規性 當需要嚴格分隔時很實用 (例如,地區法律) 當落地允許集中化時運作最佳
成本 授權與管理成本愈高 更具成本效益;多個組織的一個授權
監管 分割;各組織的原則不同 組織之間的集中化一致原則
資料孤立 每個組織都有自己的檢視 無 Enterprise 360 統一資料集,無重複
AI/Analytics 限制為每個組織的資料 更準確的企業範圍模型
複雜性 更多可管理的例項、更多整合 更簡單的結構,更少移動組件
績效 最適用於組織內使用個案 具有伴隨組織存取權的延遲可能增加
--- #### 建議 **偏好的模式:Data Cloud One** 若要簡化多組織企業的管治並最佳化成本,請使用具有已連線伴侶組織的單一總部組織。 **使用多個 Data 360 組織的時機:**僅在合規性、居住權或組織自主權嚴格要求時使用多個 Data 360 組織 (例如,如果歐洲營運必須因為法規而保持完全與美國營運分開)。 **如何在 Data Cloud One 中選擇主組織:**從考量其中一個主要組織開始,通常是大多數業務執行的組織。在其中佈建 Data 360 可將複雜性降到最低,並將早期價值最大化。 只有在沒有現有組織適合時,才考慮建立由 COE 小組管理的專屬首頁組織。 **一般原則:** 在多組織環境中,將 Data 360 組織的數量降到最低。將 Data Cloud One 作為預設模式,以減少重複項目、啟用 AI 整備並簡化管治。 ### 在 Data 360 組織之間共用資料 #### 資料共用的需求 雖然 Data Cloud One 是大多數企業的建議方法,但客戶可能必須佈建多個 Data 360 例項,包括: - **區域合規性。**一個跨國零售商在歐盟提供一個 Data 360,在美國提供另一個 Data 360。Data 360 至 Data 360 資料共用可讓公司從本機資料建立洞察,且仍可與美國總部共用洞察。 - **業務單位協同合作。**集團會針對零售和保險執行個別的 Data 360 組織。Data 360 組織之間的資料共用可讓使用者存取單一的權威資料來源,而無須移動或複製。透過 Data 360 組織之間的資料共用,保險組織會收到零售的「高價值客戶」區段,用於鎖定目標的交叉銷售行銷活動。 - **併購。**父系公司取得一個擁有自己 Data 360 的子公司。擁有兩個可管理的例項,保留短期資料孤立區可保留資料安全性和 SSOT 完整性。同時,兩個 Data 360 例項之間共用資料,可在轉換期間進行必要的協同合作。 - **聯邦執行顯示面板。**跨大陸的跨國公司會為每個區域佈建個別 Data 360 組織。主管想要聯合的每季績效檢視。每個區域 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 之類的功能會在其本機例項上獨立作業。不會自動進行共用,必須建立有意的資料共用,才能僅針對特定物件協同合作。 #### Data 360 組織之間資料共用的優點與缺點
因素 優點 缺點
資料落地 支援區域分隔,同時啟用協同合作。 不會移除管理多個 Data 360 組織的需求。
資料重複 複製零;無重複物件。 需要刻意選取要包含在每個資料共用的物件。
監管 共用是明確且有意的 (物件級)。 沒有標記或原則流程;目標組織必須重新套用監管。
複雜性 啟用不集中化的選用協同合作。 需要管理多個 Data 360 組織和資料共用。
**AI/Analytics** 可進行區域 AI/分析;洞察可在組織之間共用。 除非有意共用資料,否則不會有企業範圍 AI。
**平台功能** 每個組織的 Data 360 技術支援的功能會獨立執行。 沒有自動共用。若未仔細設計,則會有重複的風險。
成本 可能會減少 ETL 銷售管道的需求。 仍會產生多個 Data 360 組織的成本。耗用資料查詢和資料共用的信用額。
#### 決策條件
考量事項 Data Cloud One (偏好用於多組織) Data 360 組織之間的資料共用
單一事實來源 是,所有組織皆共用資料模型。 否—每個 Data 360 都有自己的資料模型。
合規性 僅在落地允許集中化時才適用。 當住所法禁止集中化時為必要。
監管 集中化,一致。 聯合;有意共用物件層級。
複雜性 移動組件愈少,愈簡單。 更複雜—需要組態資料共用和多個「資料」組織。
AI/Analytics 企業範圍 AI 模型。 區域 AI。選擇性共用洞察。
平台功能 「共用 Data 360」表示所有功能在首頁 + 伴侶之間一致運作。 功能會在每個 Data 360 中獨立執行;共用必須明確。
#### 建議 **如果您的企業有多個 Data 360 組織** - 在 Data 360 組織之間使用資料共用來跨組織協同合作,而不是建立自訂銷售管道或重複資料。 - 透過建立資料共用並將其授與目標組織,共用特定物件 (DMO、已計算洞察、區段)。 - 不會共用標記—接收組織必須重新套用標記,以進行監管、分類或 AI 增強。 **使用 Data 360 組織之間的資料共用** - 符合防止集中化的法規需求。 - 維護業務單位自主性,同時啟用選擇性協同合作。 - 提供跨多個區域的聯合主管顯示面板。 - 橋接無法立即合併的 M&A 案例。 **小心設計** 將 Data 360 至 Data 360 資料共用視為同盟策略,而非 Data Cloud One 的取代。 - 使用物件特定共用。 - 避免過度共用。 - 讓資料共用符合業務與合規性需求。 #### 記住 為 Data 360 佈建規劃資料策略是一個重要的長期結構決策,必須在企業範圍內進行,而非逐一組織進行。此早期策略選擇會決定統一客戶資料的方式、強制執行管治的方式,以及在整個組織中的重要平台功能 (尤其是 AI 和分析) 規模。請提前規劃監管與擁有權模型,並避免短期快速鍵導致後續分散並增加複雜性。 ## 資源 [Customer 360 是什麼?](https://www.salesforce.com/products/what-is-customer-360/) [Data 360 整合模式與作法](/docs/architect/zh-tw/fundamentals/guide/data360_integration_patterns_and_practices) [Data 360 結構](/docs/architect/zh-tw/fundamentals/guide/data-360-architecture) [Data 360 安全性結構](/docs/architect/zh-tw/fundamentals/guide/data360_security_architecture) **關於作者** 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 用量歸屬系統。