此文本使用 Salesforce 的自动翻译系统翻译。参加我们的调查,提供有关此内容的反馈,并告诉我们您接下来想要查看的内容。
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 模型可以访问企业范围内的客户数据。 |
- 配置与许可证绑定: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 作为配套组织连接。
| 注意事项 | 作为主页组织的现有组织(首选默认值) | 作为主页组织的新组织(替代) |
|---|---|---|
| 简单性 | 构建现有用户和数据结构,以加快设置;默认情况下,Data 360 与 Home Org 集成。 | 需要新 Salesforce 组织的许可和设置,以及额外的管理开销来管理它。 |
| 价值实现时间 | 立即使用本地 CRM 数据。 | 需要更慢的坡道集成。 |
| 治理 | 继承现有组织的基本治理模型 - 现有用户和权限集。如果组织已经处于中心位置,这可能没问题。 | 清晰的治理模式;是 CoE 主导的模式的理想选择。 |
| 合规性 | 与现有组织区域绑定的驻留。 | 灵活选择独立于现有组织的区域。 |
| 性能 | 本地 CRM 查询的最佳性能。 | 取决于同伴组织的连通性,无论是与其他组织的同一区域还是跨区域。 |
| 未来可扩展性 | 如果与 Data Cloud One 配对,效果很好;如果选择错误组织,以后更难以转换。 | 使用 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 的统一数据和元数据。
- 数据接收和统一(家庭组织)
- 所有数据接收配置(Salesforce CRM、外部源、流、批处理)仅从家庭组织进行。
- 与家庭组织绑定的 Data 360 租户执行身份解析、协调、建模,并将其统一到受信 Customer 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 Cloud One 设计为 Salesforce 平台的水平结构,与 Sandbox 非常相似。目标是 Salesforce 的每个新功能版本都可以在家庭和伴侣组织中使用,无需额外设置。这确保了 Data Cloud One 不仅仅是数据架构的选择,而且是 Salesforce 平台未来的基础元素。
| 功能 | 主页组织 | 同伴组织 |
|---|---|---|
| 连接 配置连接器、创建数据流、接收或联合数据 | ✅ | ❌ |
| 协调和统一 构建并运行数据转换和身份解析 | ✅ | ❌ |
| 使用数据空间和权限管理安全数据 | ✅ | ✅ |
| 细分和预测构建细分、见解和 Einstein Studio 模型 | ✅ | ✅ |
| 激活随处激活、数据操作 | ✅ | ✅ |
| 平台功能提示生成器、流、报表、丰富等 | ✅ | ✅ |
| 数据 360 支持功能 勘探中心、销售和 Service Cloud 功能、Agentforce 等 | ✅ | ✅ |
拥有多个组织的企业必须选择在其生态系统中定位 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。
| 注意事项 | 多个独立数据 360 | 一个共享 Data 360 (Data Cloud One ) |
|---|---|---|
| 自治 | 每个组织或业务部门的高度自主权。 | 集中管理,每个组织的自主权更少。 |
| 合规性 | 在需要严格分离时非常有用(例如,区域法律)。 | 当驻留允许集中时,效果最佳。 |
| 成本 | 更高的许可和管理成本。 | 更具成本效益;一个许可证适用于多个组织。 |
| 治理 | 分散;每个组织的策略不同。 | 跨组织的集中、一致的策略。 |
| 数据仓 | 每个组织都有自己的视图;没有 Enterprise 360。 | 统一数据集,无重复。 |
| AI/Analytics | 仅限于每个组织的数据。 | 具有更好准确性的企业范围模型。 |
| 复杂性 | 要管理的实例更多,集成更多。 | 更简单的架构,更少的移动部件。 |
| 性能 | 最适合组织内用例。 | 同伴组织访问权限可能会引入延迟。 |
**首选模式:**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 和数据共享。 |
| 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 中独立运行;共享必须明确。 |
如果您的企业有多个 Data 360:
- 使用 Data 360 组织之间的数据共享进行跨组织协作,而不是构建自定义漏斗或复制数据。
- 通过创建数据共享并将其授予目标组织来共享特定对象(DMO、计算见解、细分)。
- 请注意,标记不是共享的 — 接收组织必须重新应用标记(例如,治理、分类、AI 丰富)。
何时使用 Data 360 组织之间的数据共享:
- 满足防止集中化的法规要求。
- 保持业务部门的自主权,同时启用选择性协作。
- 跨多个区域提供联合主管仪表板。
- 弥补无法立即整合的并购情况。
精心设计
共享必须是有意的,并且特定于对象。避免“过度共享” - 使数据共享与业务和合规需求保持一致。将 Data 360 到 Data 360 数据共享视为联合策略,而不是 Data Cloud One 的替代。
- 每个组织都应计划对 Data 360 的访问权限
- 今后,从 Sales Cloud 和 Service Cloud 到 Agentforce 的所有 Salesforce 平台功能都需要 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 优先模型发展,其中从客户细分到 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 使用归因系统。