Org 策略是全景层面的决定

🌐 另有 28 种语言版本

English · Español · 日本語 · Português (Brasil) · Français · Deutsch · Italiano · 한국어 · Português (Portugal) · 繁體中文 · Bahasa Indonesia · Türkçe · Polski · Tiếng Việt · ไทย · Nederlands · العربية · עברית · Українська · हिन्दी · Русский · Svenska · Dansk · Norsk bokmål · Suomi · Español (México) · Français (Canada) · Deutsch (Schweiz)

图片由 AI 生成

由 AI 翻译，尚未经过社区审校。 阅读英文版

第 5 个模块，共 6 个，属于 Data Architect 课程第 4 章理解企业数据。每个模块都可以单独阅读。 上一篇：画出系统全景图 · 下一篇：Steve Trucking 的全景图

**本模块回答的问题：**一个 org 还是多个，它在哪里运行？

我教 CTA 考生时会告诉他们，一个情景中最大的决定出现在最初的五到十分钟：**我们面对的是多少个 Salesforce org？**一个大 org？北美、EMEA 和亚太各一个区域 org？不同业务部门各用一个 org？为一个有自己规则的国家单独建一个 org？紧接着与之相关的是：这些 org 在哪里运行？

这些不是管理员层面的细节。它们会改变数据放在哪里、集成、报表、身份，以及世界各地的人如何访问系统。这就是为什么我把 org 策略当作全景层面的决定，也是为什么我最先做这个决定。

从一个 org 开始

我的出发点很简单：**从一个 org 开始。**不是因为一个 org 总是对的，而是因为我需要一个理由才会再加一个。一个 org 给了我一个存放共享客户数据的地方，一个安全模型，一个部署的地方，一套集成，一个做报表的地方。而一个 org 仍然可以支持不同的业务部门、国家、流程、记录类型、应用、共享模型和体验。

所以我不会因为欧洲的做法有点不同、某个事业部有自己的销售流程，或者业务部门之间互相看不顺眼，就加一个 org。这些是需求，不是 org 的边界。问题是：什么力量强大到足以证明需要另一个 org？

多个 org 是有代价的

把一个 org 拆成三个（北美、欧洲、亚太），你画出的并不是三个整齐的方框；你制造了新的问题。一个全球客户放在哪里？如果它在两个区域都有业务：两份副本，哪一份拥有它？怎么做全球报表？ERP 要和三个 org 都集成吗？数据仓库要接收三个数据源吗？身份提供商要连接三个 org 吗？我们要把同样的功能部署三次，并让三个数据模型保持一致吗？如果一个智能体需要一个客户的全球视图，它该问哪个 org？

回到模块 4 的全景图。一个 Salesforce 方框变成三个，每一个箭头都要重画。多 org 并没有错。但它从来都不是免费的。

寻找真正的边界

什么能证明需要另一个 org？足以塑造架构的真实边界：数据驻留、监管、法律上的隔离、真正不同的运营模式、尚未整合的收购、区域托管约束、截然不同的治理方式，有时还有规模或隔离的需要。这份清单并不完整。重点是区分**“这些群体不一样”和“这些群体需要一条架构边界”**。后者的门槛要高得多。

地理位置并不自动构成 org 策略

“我们在 30 个国家运营，所以需要 30 个 org。”不对。地理位置只有在带来架构需求时才重要。一家公司可以让全世界的用户使用同一套通用架构。所以我不数国家；我问的是随之而来的是什么。数据可以存储在哪里？可以在哪里处理？跨境传输个人数据有没有限制？有没有关于数据驻留的合同承诺？某个区域是否需要不同的 Salesforce 服务或托管方？“在德国有一个办公室”本身是不够的。

托管是图的一部分

在这里，现代平台让全景图变得更有意思。Hyperforce 在世界各地区域的公有云基础设施上运行 Salesforce，让客户对数据驻留在哪里有更多选择和控制（Salesforce Hyperforce: General Information and FAQ (opens in a new tab)，英文）。所以当我给一个方框标上“Salesforce，欧洲”时，这个位置是可能重要的。

但要说得准确。选择一个 org 放在哪里，并不是承诺每一项服务的每一个字节都留在那里。Salesforce 提醒客户查阅 Hyperforce 的信任与合规文档，包括他们所购买服务的额外子处理方（同一来源）。所以不要说“我们在 X 国的 Hyperforce 上，所以一切都留在 X 国”。要知道你实际在用哪些服务，以及你在满足哪项需求。还要注意你选择的是什么：是区域，而不是它下面的云。Hyperforce 运行在 AWS 上，从 2026 年底起也运行在 Google Cloud 上，由 Salesforce 决定一个 org 放在哪家提供商上；如果客户有书面的监管理由需要避开某一家，就要和它的客户团队沟通（同一来源）。

不要扮演律师

这也是架构师需要清楚自己角色的地方。如果有人说“欧洲的隐私法要求单独一个 org”，我不会盲目接受。我也不会自封为公司的律师，宣布它并不要求。我会问：**我们要满足的具体需求是什么？**数据存储在哪里、在哪里处理、跨境传输、谁可以为了支持而访问它、一份合同、内部政策？然后我和隐私、安全、合规及法务团队一起，把这项需求转化为架构。不要编造法律要求，也不要忽视它们。把它们翻译出来。

当欧洲有了自己的 org

这是我在真实情景中看到的一条边界。一家公司在美国有大量业务，在欧洲也有大量业务：两大客户群，两套销售和服务运营，以及一个围绕 GDPR 建立的欧洲隐私计划。GDPR 并没有说“你需要一个单独的 Salesforce org”。它为个人数据制定规则，包括个人数据何时可以被传输到欧盟以外（GDPR, Chapter V (opens in a new tab)，英文）。但这家公司与它的隐私和法务团队一起决定，它的欧洲客户的个人数据应该放在一个托管在欧洲的 org 里，由它的欧洲团队运营，受它的欧洲治理约束。这是一个真实的需求，而且是他们的需求，不是我的。

现在，“一个大的全球 org”就不再是一种偏好了。全景图上有了一条边界，Salesforce AMER 和 Salesforce EMEA，我必须把它画出来。而第二个 org 从来不只是多一个方框。

Click to enlarge

两个 org，AMER 和 EMEA。琥珀色是第二个 org 所增加的：不是多一个方框，而是每个箭头都要再来一遍。

再走查一遍箭头

有了不止一个 org，就再走查一遍全景图。ERP 要把产品发给每个 org 吗？每个 org 都要把订单发回去吗？客户在哪里主控，他们的数据可以跨区域吗？集成层是全球的还是区域的？哪个身份提供商为哪些用户登录？分析数据去哪里？

有三个地方最快暴露出代价：

**报表。**CEO 想要一份全球销售管道。在一个 org 里，那是一份 Salesforce 报表。在三个 org 里，那就是一个企业报表问题：复制、发送到数据仓库，还是联邦访问？它必须多新？这几个 org 对“销售管道”的定义是否一致？**分析放在哪里，取决于数据放在哪里，**如果你有意把运营数据拆开了，就必须设计洞察如何重新汇聚起来。

**主数据。**一个全球客户在美国、德国和日本都有采购。三个 org，所以很可能有三个客户记录。你怎么知道它们是同一家公司？全球标识符是什么，归谁所有？如果一个区域改了地址，这个修改应该传播出去吗？哪些属性是全球的，哪些是区域的？org 策略解决不了身份问题；它改变的是身份问题本身。那是第 6 章的内容。

**集成。**一个 org：Salesforce、集成层、ERP。三个 org：三条连入集成层的连接，其中一条可能有自己的托管方和网络连接，有些数据流是共享的，有些是区域的，有些数据允许跨越，有些不允许。甚至网络也可能变化：如果企业需要通往 Hyperforce 的专用私有连接（在 AWS 上，Salesforce 推荐 AWS Direct Connect；见同一份 Hyperforce 常见问题），图上的每一个 org 和托管方都是又一条需要规划的连接。一个 org 在哪里运行，可能会改变企业其余部分访问它的方式。

**一个 org 还是多个，是你现在就要做的决定，**在一开始，在全景图上。之后这些 org 如何共享数据（跨 org 的 Salesforce Connect、它们之间的集成、Data 360）属于机制层面，由第 14 章一个 org 还是多个？ *(coming soon)*来讲。

如果你设计完整个数据模型和集成架构之后才听到“顺便说一下，这得是三个 org”，你做的就不是一次小调整。你改变了架构。这就是为什么这个决定要最先做。

不要只为了让方框变小而拆分

一个大 org 感觉很复杂：很多部门、对象、用户、集成。有人说：“如果每个人都有自己的 org，不是更干净吗？”图也许会更干净。企业却未必。你用内部的复杂度换来了分布式的复杂度：同步、重复数据、跨 org 身份、全球报表、好几条发布流水线、重复的集成和自动化，以及对这一切的治理。有时这仍然是正确的交换。但分开不等于简单。

而一个 org 也不是免费的。共享治理变得更重要，团队之间会互相影响，安全边界需要仔细设计，数据模型必须服务很多群体，发布需要协调，区域性的规则可能会约束所有人。所以这不是“Steve 说永远只用一个 org”。我的出发倾向是一个 org；然后我去寻找足以让我偏离它的强有力的需求。

让决定看得见

如果 org 策略很重要，就不要画一朵笼统的 Salesforce 云。把各个 org 画出来并标上名字（AMER、EMEA，无论实际是什么），注明每个 org 背后的托管或驻留需求，并走查各个连接。另一位架构师应该能看出每条边界为什么存在。如果我解释不了为什么有三个 Salesforce 方框，我就还没做完这个决定。

Steve Trucking 只有一个 org，在美国，它的简介里也没有任何需要另一个 org 的东西。但在综合项目中记住这个模块：一次带着自己 org 到来的收购，正是检验这些问题的那种边界。

**考试之外：AI 改变了什么。**智能体可以让 org 边界对用户不可见。但在底层，架构仍然必须决定智能体可以问哪个 org 或系统，哪些数据可以跨区域，以及哪个答案是权威的。AI 可以在体验中隐藏复杂度；它不会消除治理或边界。

架构师在这里决定什么

• 是否有真正的架构理由需要不止一个 org，而不是在一个 org 内部解决这些差异。
• 每个 org 在哪里运行，以及是哪项驻留、监管、合同或业务需求让它放在那里。
• 哪些数据可以跨越 org 和区域的边界，主数据在哪里是权威的，以及全球身份如何运作。
• 当一个 Salesforce 方框变成好几个时，集成、身份、分析和报表会如何变化。
• 分开带来的好处是否值得它所制造的分布式架构。

读一个情景时，我首先寻找这个决定：一个 org 还是多个，托管在哪里，被什么所迫？回答了这些，全景图的其余部分就开始成形了。

延伸探索

• Salesforce Help，Salesforce Hyperforce: General Information, FAQ, Migration Guide, and Security Overview (opens in a new tab)（英文），查阅日期 2026-10-14。
• EUR-Lex，Regulation (EU) 2016/679, the General Data Protection Regulation (opens in a new tab)（英文），第五章（向第三国传输个人数据），查阅日期 2026-10-14。