--- schema_version: "1" id: cbc8dc54b399a9d58512c8bb486e76e26f58c838df4540eaa4b994752ae2fbd7 title: Data 360 配置 collection: architect version: next locale: zh-cn portal_url: https://docs.salesforce.com/architect/next/zh-cn/decision-guides/guides/data-360-provisioning.md canonical_url: https://staging.architect.salesforce.com/docs/architect/zh-cn/decision-guides/guide/data-360-provisioning.html source_site: staging.architect.salesforce.com content_type: documentation content_hash: 33be517ab20dac1006973dfe9a16d592b7b3f4fb64f9fe9546dfb95f65bae51f products: - 决策指南 - Architect Site Content Repo updated_at: 2025-10-01T00:00:00Z --- ## 概览 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 组织之间的数据共享，或者将哪个组织指定为家庭组织 — 都应该根据这些交叉注意事项进行评估：
注意事项 为何如此重要 示例场景
数据驻留与合规 确定数据的存储和处理位置。监管规则可能需要特定区域或多个实例。 一家全球银行在位于法兰克福的 Salesforce 组织中配置了一个 Data 360 租户，以满足 GDPR 合规性要求，并在弗吉尼亚州的一个组织中为其美国分部配置了另一个租户。
治理和安全 谁拥有和管理 Data 360？保单是集中管理还是按业务部门委派？ 一家拥有强大中央 IT 的跨国公司创建了由卓越中心管理的专用家庭组织。
自主与集中 不同的领导可能需要单独的数据所有权。自治支持多个 Data 360；集中支持 Data Cloud One。 拥有独立子公司的控股公司允许每个业务部门运行自己的 Data 360。
延迟和性能 影响查询速度和体验，特别是对于跨区域连接到 Data 360 租户的同伴组织。 伦敦的销售团队从美国的 Data 360 租户查询数据时，可能会看到更高的延迟。
集成复杂性 更多 Data 360 租户 = 更多漏斗、API 和中间件。整合简化了集成。 零售商通过整合到 Data Cloud One 配置中，避免了构建 10 个 ETL 漏斗。
零复制数据源区域 Zero Copy 连接器可能有跨区域访问要求，限制 Data 360 可以位于哪些区域。 一家公司在 AWS eu-west-1 地区拥有 Snowflake 实例。他们可以使用 Zero Copy 将数据合并到他们区域的 Data 360，但无法使用 Zero Copy 合并到美国区域的 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 模型可以访问企业范围内的客户数据。
### 重要注意事项 --- ## 第 1 部分：配置数据 360 – 选择家庭组织 ### 1.1 什么是 Data 360 家庭组织？ 在您购买 Data 360 许可证时，Data 360 实例将在与该许可证关联的 Salesforce 组织中配置。该组织称为 Data 360 主页组织。 显示 Data 360 主页组织的决策图 主页组织是 Data 360 实例的锚。它位于： - 管理 Data 360 存储和计算（在配置时选择的区域）。 - 应用管理、治理和安全策略。 - 执行数据接收、协调、身份解析、细分和激活。 在多组织场景中，家庭组织管理其他 Salesforce "Companion" 组织的中央 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 与 Home Org 集成。 需要新 Salesforce 组织的许可和设置，以及额外的管理开销来管理它。
价值实现时间 立即使用本地 CRM 数据。 需要更慢的坡道集成。
治理 继承现有组织的基本治理模型 - 现有用户和权限集。如果组织已经处于中心位置，这可能没问题。 清晰的治理模式；是 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 月，约有 19000 个 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 的工作方式
  1. 数据接收和统一（家庭组织）
  2. 数据空间架构
  3. 元数据共享
    同伴组织从家庭组织接收元数据定义，包括数据模型对象 (DMO)、统一简档模式、计算见解、细分等。这些资产在同伴组织中本地显示，如同本地资产，但实际上与家庭组织相关联。
  4. 在家组织中要完成的工作与同伴组织
    5. 家庭组织和伴侣组织之间的功能访问权限不同。同伴组织无法接收或统一数据，需要依赖家庭组织进行接收、建模和统一。同伴组织可以访问 Data 360 数据，以支持 Data 360 支持的平台功能，他们可以在共享的可信数据上创建本地见解、细分和流。在未来的愿景中，他们还可以访问激活功能。
    功能 主页组织 同伴组织
    连接 配置连接器、创建数据流、接收或联合数据 ✅ ❌
    协调和统一 构建并运行数据转换和身份解析 ✅ ❌
    使用数据空间和权限管理安全数据 ✅ ✅
    细分和预测构建细分、见解和 Einstein Studio 模型 ✅ ✅
    激活随处激活、数据操作 ✅ ✅
    平台功能提示生成器、流、报表、丰富等 ✅ ✅
    数据 360 支持功能 勘探中心、销售和 Service Cloud 功能、Agentforce 等 ✅ ✅
  5. 平台功能奇偶性
    从用户和生成器的角度来看，一旦元数据被共享，在使用 Salesforce 平台功能方面，主页和同伴组织之间有一些功能差异。支持的功能列表可在 Data 360 功能 中找到。
  6. 消耗模型
    所有同伴组织活动（查询、细分运行、Data 360 触发的流、AI 使用、Einstein Trust 层日志等）都会消耗来自家庭组织的 Data 360 信用。消费流单向流动：根据家庭组织的信用分配，对信用进行集中、计费和跟踪。但您可以深入了解每个个人组织在 Digital Wallet 中使用的信用数量。
  7. 设计原理：水平构造
    Data Cloud One 设计为 Salesforce 平台的水平结构，与 Sandbox 非常相似。目标是 Salesforce 的每个新功能版本都可以在家庭和伴侣组织中使用，无需额外设置。这确保了 Data Cloud One 不仅仅是数据架构的选择，而且是 Salesforce 平台未来的基础元素。
--- ### 2.3 决策：多个独立数据 360 与一个共享 Data 360 (Data Cloud One) 拥有多个组织的企业必须选择在其生态系统中定位 Data 360 的方式和位置。他们是想要在每个组织中配置独立的 Data 360，还是使用 Data Cloud One 将组织统一到一个家庭组织下？ #### 选项 A：多个独立数据 360 每个 Salesforce 组织配置自己的 Data 360 实例。 **优点**: - **自治**:每个业务部门或区域控制自己的 Data 360。 - 每个组织内的**简单性**：治理、安全和自定义已本地化。 - **监管合规**:在需要严格监管分离时非常有用（例如，数据不得跨越边界）。 **缺点**: - **数据孤岛：**Customer 360 不能跨组织实现。 - **成本较高**:每个实例都需要许可、管理和集成。客户最终会多次接收相同的源数据，以便在多个不同的组织中实现完整的 C360 视图。 - **重复工作：**必须在每个 Data 360 中重复身份解析、细分和丰富。 #### 选项 B：一个共享数据 360（Data Cloud One 群集） 单个 Data 360 在家庭组织中配置，其他 Salesforce 组织作为同伴组织连接。 **优点**: - **单一真相来源 (SSOT)：**所有组织共享相同的统一数据模型。 - **成本效率：**只有一个 Data 360 许可证和基础设施需要管理。 - **统一治理：**策略、安全性和合规性控制集中应用。 - **跨组织丰富：**同伴组织可以访问统一的简档、见解和细分。 - **AI 就绪：**企业范围的数据集支持更好地训练和激活 AI 模型。 - **未来证明：**添加新的同伴组织很简单；不需要新的 Data 360。 **缺点**: - **其他准备：**需要规划组织到家庭的组织连接。 - **延迟注意事项：**不同地区的同伴组织可能会看到查询变慢。 - **复杂治理：**如果每个组织都有非常不同的自定义需求，那么细粒度治理可能很复杂。 #### 选项 C：多个 Data Cloud One 群集 在某些情况下，治理、合规性或其他业务需求会使将每个组织群集在一起不切实际。这可能会导致需要实施一个混合解决方案，其中企业操作几个 Data 360，每个都是不同同伴组织集群的家庭组织。 #### 示例： 跨国公司在多个地区拥有 Salesforce 组织，包括欧洲、美国和亚洲。为了遵守区域数据驻留条例，他们为每个单独的区域配置了一个 Data 360。 #### 决策条件
注意事项 多个独立数据 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、潜在客户中心、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 组织之间的数据共享：** - 满足防止集中化的法规要求。 - 保持业务部门的自主权，同时启用选择性协作。 - 跨多个区域提供联合主管仪表板。 - 弥补无法立即整合的并购情况。 **精心设计** 共享必须是有意的，并且特定于对象。避免“过度共享” - 使数据共享与业务和合规需求保持一致。将 Data 360 到 Data 360 数据共享视为联合策略，而不是 Data Cloud One 的替代。 --- ## 汇总
  1. 每个组织都应计划对 Data 360 的访问权限
  2. 考虑企业范围，而不是逐个组织
  3. 最小化数据孤岛
  4. 如果您必须运行多个 Data 360，请谨慎设计
  5. 尽早规划治理和所有权
  6. 避免短期快捷方式
这些配置选择至关重要，因为 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 使用归因系统。