Data 360 配置

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

由于并购、区域运营、功能分离或历史原因，企业通常运营多个 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 进行 Customer 360、AI 和跨平台创新。使用此指南确定哪些组织需要 Data 360，以及是使用 Data Cloud One 还是 Data 360 组织之间的数据共享。此策略为以 Data 360 为中心的未来奠定了坚实的基础。

• **每个组织都应计划对 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 组织之间的数据共享来实现安全协作。

• **为协作而不是自定义 ETL 漏斗设置 Data 360 组织之间的数据共享。**通过数据共享，共享特定对象（DMO、计算见解、细分）。请谨记，标记不会共享，消耗会向源组织计费。

• **避免短期捷径。**如果没有长期计划，请勿将多个 Data 360 组织拆分为概念验证 (POC)。将试点和早期部署与企业范围的配置策略保持一致。

根据这些交叉注意事项，评估每个配置选择（在 Data Cloud One、Data 360 组织之间的数据共享或家庭组织指定之间进行选择）。

有三个主要用例需要为 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 集成模式和实践。

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

备选案文A:在现有组织中配置 Data 360

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

• 优点:

  • 最简单的路径：Data 360 配置在您的 CRM 数据所在的位置。

  • 立即访问本地销售、服务和市场营销数据。

  • 不需要额外的集成。

  • 需要管理的许可证和环境更少。

  • 加速早期采用、试点和生产用例。

• 缺点:

  • 可以继承现有组织的治理或技术债务。

  • 如果不存在单个“主要组织”，选择一个组织可以创建所有权辩论。

  • 绩效与组织的位置相关；可能与企业范围的驻留需求不一致。

  • 如果多个业务部门使用不同的组织，如果不与 Data Cloud One 配对，本地配置可能会导致碎片化。

示例：

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

备选案文B:在新的专用组织中配置 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 的统一数据和元数据。

Data Cloud One 的工作方式

• 数据接收和统一（家庭组织）

  • 所有数据接收配置（Salesforce CRM、外部源、流、批处理）仅从家庭组织进行。

  • 与家庭组织绑定的 Data 360 租户执行身份解析、协调、建模，并将其统一到受信客户简档中。

  • Data 360 管理、治理策略、标记和屏蔽从家庭组织集中应用。

• 数据空间架构

  • 从主组织中，数据被组织成数据空间，它们充当数据、元数据和流程的逻辑容器。

  • 企业可以为品牌、地区或业务线创建数据空间。

  • 数据空间共享：从主组织中，特定数据空间有选择地与伴随组织共享。这将确保只有相关数据（和相关元数据）流向正确的组织。

• 元数据共享

  同伴组织从主组织接收元数据定义，包括数据模型对象 (DMO)、统一简档模式、计算见解、细分等。这些资产会本地显示在伴随组织中，如同本地资产，但会链接到本地组织。

• 家庭组织与同伴组织中的功能 家庭组织和伴侣组织之间的功能访问权限不同。配套组织无法接收或统一数据，需要依赖家庭组织进行接收、建模和统一。同伴组织可以访问 Data 360 数据，以支持 Data 360 支持的平台功能，他们可以在共享的可信数据上创建本地见解、细分和流。在未来的愿景中，他们还可以访问激活功能。

• 平台功能奇偶性 从用户和构建者的角度来看，一旦元数据被共享，在使用 Salesforce 平台功能方面，家庭和伴随组织之间存在一些功能差异。支持的功能列表可以在 Data 360 功能 中找到。

  • 一旦元数据可用，Salesforce 平台功能（例如流、报表、提示生成器、仪表板和其他平台原生工具）可在家庭和伴随组织中正常工作。

  • Data 360 支持的功能，例如 Agentforce、Prospecting Center、Sales Cloud Einstein 功能和 Service Cloud AI 功能，也可以在家庭和伴随组织中无缝工作。一些功能可能即将实现完全兼容，但总体目标是，对于所有依赖于 Data 360 的跨云功能，在家庭和伴随组织之间实现功能对等。

• 消耗模型 所有伴随的组织活动(查询、细分运行、Data 360 触发的流、AI 使用、Einstein Trust 层日志记录等)都会消耗家庭组织的 Data 360 信用。消费流单向流动：根据家庭组织的信用分配，对信用进行集中、计费和跟踪。但您可以深入了解每个个人组织在 Digital Wallet 中使用的信用数量。

• 设计原理：水平构造 Data 360 中的水平构造是一项基础设计原则，主要通过 Data Cloud One 实施，它允许单个 Data Cloud 实例跨越多个不同的 Salesforce CRM 组织。目标是，每个新发布的功能都可以在家庭和伴随组织中使用，无需额外设置。此功能确保 Data Cloud One 不仅仅是数据架构选择，而且是 Salesforce 平台未来的基础元素。

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

备选案文A:多个独立数据 360 组织

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

优点:

• **自治：**每个业务部门或区域控制自己的 Data 360。

• **每个组织内的简单性：**治理、安全和自定义已本地化。

• **法规遵从性：**在需要严格监管分离时非常有用（例如，数据不得跨越边界）。

缺点:

• **数据孤岛：**无法在组织之间实现统一简档。

• **成本较高：**每个实例都需要许可、管理和集成。客户最终会在多个不同的组织中多次接收相同的源数据。

• **重复工作：**身份解析、细分和丰富必须在每个 Data 360 实例中重复。

备选案文B:一个共享数据 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 Cloud One

为了简化多组织企业的治理并优化成本，请使用单个家庭组织与连接的伴随组织。

**何时使用多个 Data 360 组织：**仅在合规、驻留或组织自治严格要求时使用多个 Data 360 组织（例如，如果欧洲运营由于监管必须与美国运营保持完全分离）。

**如何在 Data Cloud One 中选择主页组织：**首先考虑您的主要组织之一，通常是大部分业务运行的地方。在此配置 Data 360 可以最大限度地减少复杂性，并最大限度地提高早期价值。

请考虑创建一个由 COE 团队管理的专用家庭组织，前提是现有组织不适用。

概况:

在多组织环境中，最大限度地减少 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 的子公司。通过两个实例来管理，保留短期数据孤岛可以保护数据安全和 SSOT 完整性。同时，在两个 Data 360 实例之间共享数据允许在迁移期间进行必要的协作。
• **联合执行仪表板。**一家跨大陆的跨国公司为每个地区配置了 360 个单个 Data 组织。主管需要联合季度绩效视图。每个区域 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、Prospecting Center 和 Tableau Next 等平台功能在相同的基础数据上运行。

• 在 Data 360 组织之间使用数据共享时，每个组织都有自己的 Data 360。组织 A 和组织 B 中的 Agentforce 等功能各自独立地在本地实例上运行。不会自动进行共享 — 必须创建蓄意的数据共享，以便仅在特定对象上协作。

如果您的企业有多个 Data 360 组织

• 使用 Data 360 组织之间的数据共享进行跨组织协作，而不是构建自定义漏斗或复制数据。

• 通过创建数据共享并将其授予目标组织来共享特定对象（DMO、计算见解、细分）。

• 标记不共享 — 接收组织必须重新应用标记，以进行治理、分类或 AI 丰富。

在 Data 360 组织之间使用数据共享

• 满足防止集中化的法规要求。

• 保持业务部门的自主权，同时启用选择性协作。

• 跨多个区域提供联合主管仪表板。

• 弥合无法立即整合的并购场景。

精心设计

将 Data 360 到 Data 360 数据共享视为联合策略，而不是 Data Cloud One 的替代品。

• 使用特定于对象的共享。
• 避免过度共享。
• 使数据共享与业务和合规需求保持一致。

为 Data 360 配置规划数据策略是一项关键的长期架构决策，必须在企业范围内处理，而不是逐个组织处理。这种早期战略选择决定了如何统一客户数据，如何实施治理，以及基本平台功能（特别是 AI 和分析）如何在组织中扩展。提前规划治理和所有权模式，避免短期捷径导致分散，稍后增加复杂性。

什么是 Customer 360?

Data 360 集成模式和实践

Data 360 架构

Data 360 安全架构

关于作者

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 使用归因系统。