Salesforce Data 360 是基于 Hyperforce 构建的数据平台，它将 Salesforce 和外部数据统一到每个客户或客户的清晰、完整和可信的 360 度视图中。

由于并购、区域运营、功能分离或历史原因，企业通常运营多个 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 访问权限的策略来验证您的架构也很重要。Sales、Service、Marketing、Commerce、Industry 和 Agentforce 中的 Salesforce 功能越来越多地构建在 Data 360 上。想要使用这些平台功能的组织必须配置自己的 Data 360 或连接到作为伴随组织的共享 Data 360。

本指南帮助架构师设计配置策略，平衡简单性、企业范围的一致性、合规性和可扩展性，确保组织可以自信地利用 Data 360 进行 Customer 360、AI 和跨平台创新。这将帮助您决定如何选择在哪个组织上配置 Data 360，以及如何在 Data Cloud One 和 Data 360 组织之间的数据共享之间进行选择，从而帮助奠定坚实的基础，将您的业务推向以 Data 360 为中心的未来。

每个配置选择 — 无论是选择 Data Cloud One 还是 Data 360 组织之间的数据共享，或者将哪个组织指定为家庭组织 — 都应该根据这些交叉注意事项进行评估：

• 配置与许可证绑定：Data 360 在购买 Data 360 许可证的组织中配置，区域由该组织在配置时的位置决定。
• 即使您现在不需要，也可以通过计划 Data 360 来保持选项开放。如果您实施 Data 360 以在稍后支持 Agentforce 等平台功能，您现在做出的决策可以让您顺利发展。
• 单组织客户：在现有生产组织中配置 Data 360，以加快实现价值。
• 多组织客户：通过创建尽可能少的 Data 360 实例来最小化复杂性，理想情况下使用 Data Cloud One 配置。
• 多个 Data 360 实例应仅在合规、驻留或组织自治要求时使用。在这些情况下，使用 Data 360 组织之间的数据共享来实现安全协作。
• 零复制数据源：密切关注各种公共云和 Zero Copy 数据源支持哪些区域。此外，确定安全状况是否需要专用连接来连接到这些数据源，以及是否支持区域内或跨区域连接。
• 治理和自治是核心概念:决定 Data 360 是否应集中管理(卓越中心模式)或单个业务线是否需要单独管理的 Data 360 实例。

在您购买 Data 360 许可证时，Data 360 实例将在与该许可证关联的 Salesforce 组织中配置。该组织称为 Data 360 主页组织。 主页组织是 Data 360 实例的锚。它位于：

• 管理 Data 360 存储和计算（在配置时选择的区域）。
• 应用管理、治理和安全策略。
• 执行数据接收、协调、身份解析、细分和激活。

在多组织场景中，家庭组织管理其他 Salesforce "Companion" 组织的中央 Data 360 实例。

家庭组织为何重要：

• 它决定了 Data 360 实例的地理位置。
• 它确定谁拥有和管理您的 Data 360 实例。Data 360 主页组织中的管理员可以访问接收到 Data 360 中的所有数据。
• 它控制 Data Cloud One 配置中的同伴组织连接。
• 它为您的企业数据策略奠定了基础 — 稍后更改它很困难，并且具有破坏性。

第一个主要决策是在现有生产组织中配置 Data 360，还是创建新的专用组织作为家庭组织。

**最适合：**拥有单个 Salesforce 组织的客户，或已经拥有主要集中组织（大部分业务都在其中运行）的多组织客户。

• 优点:

  • 最简单的路径：Data 360 配置在您的 CRM 数据已经存在的地方。
  • 立即访问本地销售、服务和市场营销数据。
  • 无需额外集成。
  • 需要管理的许可证和环境更少。
  • 加速早期采用、试点和生产用例。

• 缺点:

  • 可能继承现有组织的治理或技术债务。
  • 如果不存在单个“主要组织”，选择一个组织可能会引起所有权辩论。
  • 绩效与组织的位置相关；可能与企业范围的驻留需求不一致。
  • 如果多个业务部门使用不同的组织，如果不与 Data Cloud One 配对，本地配置可能会导致碎片化。

示例：
一个拥有 Salesforce 组织的 SaaS 公司在该组织中配置 Data 360，以统一客户订阅和支持数据。

**最适合：**拥有多个 Salesforce 组织且无法在单个主要组织上保持一致的客户，或拥有强大卓越中心 (CoE) 模式的企业。

• 优点:

  • 治理清晰，没有继承的组织复杂性。
  • 跨多个业务线的集中控制。
  • 根据合规需求灵活选择地区。
  • 充当中立的“共享服务”组织，不与一个业务部门绑定。
  • 为未来的 Data Cloud One 架构（具有多个配套组织的家庭组织）设置。

• 缺点:

  • 客户必须获得新 Salesforce 组织的许可证，才可以配置 Data 360。
  • 通过 Data Cloud One 配套连接，将组织连接到 Data 360 需要额外的集成。
  • 可能会增加管理开销（用户管理、安全性、身份）。
  • 与现有生产组织中的配置相比，价值实现时间更慢。

示例：
一家跨国金融服务公司创建了一个专门的家庭组织来配置 Data 360。所有业务部门组织（零售、财富、商业银行）都通过 Data Cloud One 作为配套组织连接。

作为一般原则，赞成使用现有的主要组织作为您的家庭组织，以最大限度地减少初始工作并加快采用。仅当您的长期治理或合规战略需要时，才创建新的专用家庭组织。对于拥有卓越中心 (COE) 的大型企业来说，创建新的专用家庭组织是常见的选择。

单个组织环境

在现有生产组织中配置 Data 360。这最大限度地提高了简单性和即时价值。它避免了不必要的集成开销。

多个组织环境

倾向于选择一个主要组织（通常是您大部分业务所在的组织，或已经作为您的集中 CRM 的组织）作为家庭组织。这降低了复杂性，最大限度地减少了设置工作，并允许您快速实现 Data 360 的价值。使用现有的主要组织还避免了管理新环境的成本和集成工作。

何时考虑新的专用家庭组织

如果您的组织拥有强大的卓越中心 (CoE)，并希望治理独立于业务部门组织。如果由于合规性或组织限制，没有一个现有组织适合。在这些情况下，创建新的家庭组织提供了灵活性和中立性，但价值实现时间变慢。

企业通常运营多个 Salesforce 组织，这不是边缘个案，而是常规。截至 2024 年 2 月，约有 19000 个 Salesforce 客户已经运行了多个 Salesforce 组织。

为什么会发生这种情况？

• **收购和合并：**新收购的公司自带 Salesforce 实例。
• **区域行动:**欧盟、北美、亚太地区等地区的单独组织，通常满足数据驻留法。
• **职能分离：**不同的业务部门(例如 Retail Banking、 Wealth Management、 Insurance)保持自己的组织自治。
• **监管或安全隔离：**出于合规性原因，某些行业要求组织具有逻辑上不同的特性。
• **历史/技术原因：**随着时间的推移，客户会有机地累积多个组织。

每个原因单独有意义，但它们共同造成了数据的碎片化。如果没有统一层，每个组织只有部分客户视图。

架构挑战：如何在遵守合规性、治理和自治要求的同时，将跨组织的数据统一到单一的真实来源？

Data Cloud One 是 Salesforce 的多组织连接架构，允许多个 Salesforce 组织共享一个 Data 360 实例。它是具有多个 Salesforce 组织的企业的推荐模式。

在任何 Data Cloud One 群集中，一个 Salesforce 组织被指定为托管 Data 360 实例的家庭组织。其他 Salesforce 组织作为同伴组织连接，使用来自家庭组织 Data 360 的统一数据和元数据。

1. 数据接收和统一（家庭组织）
   
   • 所有数据接收配置（Salesforce CRM、外部源、流、批处理）仅从家庭组织进行。
   • 与家庭组织绑定的 Data 360 租户执行身份解析、协调、建模，并将其统一到受信 Customer 360 简档中。
   • Data 360 管理、治理策略、标记和屏蔽从家庭组织集中应用。
2. 数据空间架构
   
   • 从主页组织中，数据被组织成数据空间，它们充当数据、元数据和流程的逻辑容器。
   • 企业可以为品牌、地区或业务线创建数据空间。
   • 数据空间共享：从主页组织中，特定数据空间有选择地与同伴组织共享。这确保只有相关数据（和相关元数据）流向正确的组织。
3. 元数据共享
   同伴组织从家庭组织接收元数据定义，包括数据模型对象 (DMO)、统一简档模式、计算见解、细分等。这些资产在同伴组织中本地显示，如同本地资产，但实际上与家庭组织相关联。
4. 在家组织中要完成的工作与同伴组织
家庭组织和伴侣组织之间的功能访问权限不同。同伴组织无法接收或统一数据，需要依赖家庭组织进行接收、建模和统一。同伴组织可以访问 Data 360 数据，以支持 Data 360 支持的平台功能，他们可以在共享的可信数据上创建本地见解、细分和流。在未来的愿景中，他们还可以访问激活功能。

功能	主页组织	同伴组织
连接 配置连接器、创建数据流、接收或联合数据	✅	❌
协调和统一 构建并运行数据转换和身份解析	✅	❌
使用数据空间和权限管理安全数据	✅	✅
细分和预测构建细分、见解和 Einstein Studio 模型	✅	✅
激活随处激活、数据操作	✅	✅
平台功能提示生成器、流、报表、丰富等	✅	✅
数据 360 支持功能 勘探中心、销售和 Service Cloud 功能、Agentforce 等	✅	✅

5. 平台功能奇偶性
   从用户和生成器的角度来看，一旦元数据被共享，在使用 Salesforce 平台功能方面，主页和同伴组织之间有一些功能差异。支持的功能列表可在 Data 360 功能 中找到。
   
   • 一旦元数据可用，Salesforce 平台功能（例如流、报表、提示生成器、仪表板和其他平台原生工具）可在主页和同伴组织中正常工作。
   • Data 360 支持的功能 — 例如 Agentforce、Prospecting Center、Sales Cloud Einstein 功能和 Service Cloud AI 功能 — 也可以在家庭和伴侣组织中无缝工作。一些功能可能即将实现完全兼容，但总体目标是，对于所有依赖于 Data 360 的跨云功能，在主页和伴侣组织之间实现功能对等。
6. 消耗模型
   所有同伴组织活动（查询、细分运行、Data 360 触发的流、AI 使用、Einstein Trust 层日志等）都会消耗来自家庭组织的 Data 360 信用。消费流单向流动：根据家庭组织的信用分配，对信用进行集中、计费和跟踪。但您可以深入了解每个个人组织在 Digital Wallet 中使用的信用数量。
7. 设计原理：水平构造
   Data Cloud One 设计为 Salesforce 平台的水平结构，与 Sandbox 非常相似。目标是 Salesforce 的每个新功能版本都可以在家庭和伴侣组织中使用，无需额外设置。这确保了 Data Cloud One 不仅仅是数据架构的选择，而且是 Salesforce 平台未来的基础元素。

拥有多个组织的企业必须选择在其生态系统中定位 Data 360 的方式和位置。他们是想要在每个组织中配置独立的 Data 360，还是使用 Data Cloud One 将组织统一到一个家庭组织下？

每个 Salesforce 组织配置自己的 Data 360 实例。

优点:

• 自治:每个业务部门或区域控制自己的 Data 360。
• 每个组织内的简单性：治理、安全和自定义已本地化。
• 监管合规:在需要严格监管分离时非常有用（例如，数据不得跨越边界）。

缺点:

• **数据孤岛：**Customer 360 不能跨组织实现。
• 成本较高:每个实例都需要许可、管理和集成。客户最终会多次接收相同的源数据，以便在多个不同的组织中实现完整的 C360 视图。
• **重复工作：**必须在每个 Data 360 中重复身份解析、细分和丰富。

单个 Data 360 在家庭组织中配置，其他 Salesforce 组织作为同伴组织连接。

优点:

• **单一真相来源 (SSOT)：**所有组织共享相同的统一数据模型。
• **成本效率：**只有一个 Data 360 许可证和基础设施需要管理。
• **统一治理：**策略、安全性和合规性控制集中应用。
• **跨组织丰富：**同伴组织可以访问统一的简档、见解和细分。
• **AI 就绪：**企业范围的数据集支持更好地训练和激活 AI 模型。
• **未来证明：**添加新的同伴组织很简单；不需要新的 Data 360。

缺点:

• **其他准备：**需要规划组织到家庭的组织连接。
• **延迟注意事项：**不同地区的同伴组织可能会看到查询变慢。
• **复杂治理：**如果每个组织都有非常不同的自定义需求，那么细粒度治理可能很复杂。

在某些情况下，治理、合规性或其他业务需求会使将每个组织群集在一起不切实际。这可能会导致需要实施一个混合解决方案，其中企业操作几个 Data 360，每个都是不同同伴组织集群的家庭组织。

跨国公司在多个地区拥有 Salesforce 组织，包括欧洲、美国和亚洲。为了遵守区域数据驻留条例，他们为每个单独的区域配置了一个 Data 360。

**首选模式：**Data Cloud One

默认设置为具有多组织企业连接的同伴组织的单个家庭组织。
这将创建企业范围的 Customer 360，简化治理，并优化成本。

何时使用多个 Data 360：

仅在合规、驻留或组织自治严格要求时。例如，如果欧洲业务由于监管而必须与美国业务完全分开。

如何在 Data Cloud One 中选择家庭组织：

从考虑其中一个主要组织开始 — 通常是大部分业务运行的地方。在此配置 Data 360 可以最大限度地减少复杂性，并最大限度地提高早期价值。

仅当现有组织不适用时，才考虑创建由卓越中心团队管理的专用家庭组织。

概况:

在多组织环境中，最大限度地减少 Data 360 的数量。青睐 Data Cloud One 作为默认模式，以减少重复、启用 AI 就绪并简化治理。

虽然 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 360 实例。平台功能（Agentforce、潜在客户中心、Tableau Next 等）都在相同的基础数据上运行，从而确保了一致性。
• 在 Data 360 组织之间使用数据共享时，每个组织都有自己的 Data 360。组织 A 和组织 B 中的 Agentforce 等功能各自在本地实例上独立运行。不会自动进行共享 — 必须创建有意的数据共享，以便仅在特定对象上协作。

区域合规性：
一家跨国零售商在欧盟配置了一个 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 组织之间的数据共享进行跨组织协作，而不是构建自定义漏斗或复制数据。
• 通过创建数据共享并将其授予目标组织来共享特定对象（DMO、计算见解、细分）。
• 请注意，标记不是共享的 — 接收组织必须重新应用标记（例如，治理、分类、AI 丰富）。

何时使用 Data 360 组织之间的数据共享：

• 满足防止集中化的法规要求。
• 保持业务部门的自主权，同时启用选择性协作。
• 跨多个���域提供联合主管仪表板。
• 弥补无法立即整合的并购情况。

精心设计

共享必须是有意的，并且特定于对象。避免“过度共享” - 使数据共享与业务和合规需求保持一致。将 Data 360 到 Data 360 数据共享视为联合策略，而不是 Data Cloud One 的替代。

1. 每个组织都应计划对 Data 360 的访问权限
   
   • 今后，从 Sales Cloud 和 Service Cloud 到 Agentforce 的所有 Salesforce 平台功能都需要 Data 360 连接。每个组织必须托管 Data 360 家庭组织，或者成为通过 Data Cloud One 连接的同伴组织。
2. 考虑企业范围，而不是逐个组织
   
   • 避免孤立地做出单方面的业务决策。
   • 资源调配应集体决定，理想情况下由企业架构或数据治理理事会决定。始终预测未来的 AI 和分析需求，这取决于广泛的统一数据集。
3. 最小化数据孤岛
   
   • 为了简单和快速，在现有主要组织中优先配置 Data 360。
   • 在多组织环境中，Data Cloud One 是在一个 Data 360 下统一组织的默认模式。
   • 仅在合规、驻留或组织自治严格需要时配置多个 Data 360。
4. 如果您必须运行多个 Data 360，请谨慎设计
   
   • 为协作设置 Data 360 组织之间的数据共享，而不是自定义 ETL 漏斗。
   • 通过数据共享，共享特定对象（DMO、计算见解、细分）。
   • 请谨记：标记不共享，消耗会向源组织计费。
5. 尽早规划治理和所有权
   
   • 决定 Data 360 是集中管理（卓越中心模式）还是委派给业务部门。定义管理员、安全团队和合规潜在客户的角色。
   • 避免含糊不清:所有权不明确是常见的摩擦来源。
6. 避免短期快捷方式
   
   • 如果没有长期计划，请勿为 POC 增加多个 Data 360 — 这会在以后造成破坏性的整合工作。
   • 相反，将试点和早期部署与您的企业范围配置策略结合起来。

这些配置选择至关重要，因为 Salesforce 平台正在向 Data 360 优先模型发展，其中从客户细分到 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 使用归因系统。