选择合适的对象
另有 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)
第 5 个模块，共 10 个，属于 Data Architect 课程第 3 章Salesforce 数据架构。每个模块都可以单独阅读。 上一篇：这些数据放在哪里？ · 下一篇：字段也是架构
**本模块回答的问题：**这个业务概念应该成为哪种 Salesforce 对象，许可又允许什么？
在 Salesforce 里，最容易做的事情之一就是创建一个自定义对象。正因如此，我认为我们创建的自定义对象太多了。
你在一次需求会议上，有人说：“我们需要跟踪我们的经销商。”新建自定义对象：Distributor。搞定。可是我希望架构师先问另一个问题：**经销商是什么？**它是一家公司。Salesforce 已经有一种相当不错的方式来表示公司，它叫客户（Account）。这并不意味着答案总是客户。但如果我必须解释为什么一家公司不是客户，我希望有一个比“业务方管它们叫经销商”更好的理由。
这是第 2 章的逻辑模型与平台相遇的地方，而我的出发点很简单：如果业务概念与某个标准对象的本来用途干净契合，就从那里开始。
从含义开始
Section titled “从含义开始 ”即使某样东西值得成为一个对象，它也不会自动值得成为一个自定义对象。问一问这样东西实际上代表什么。任何形式的企业或组织？从客户开始。与这个组织打交道的一个人？联系人。客户拥有或购买的某样东西？资产。你想卖出去的某样东西？那么业务机会就该进入讨论了。
这就是为什么我们在模块 2里先看向母舰。那些模型并不适合每一个业务，但我们不应该因为自建一个感觉更干净就忽视它们。在点击 New Custom Object（新建自定义对象）之前，先问一问：Salesforce 是如何为这个概念建模的，围绕那个模型已经构建了什么，如果替换它，你会放弃什么。
干净契合测试
Section titled “干净契合测试 ”我的测试只有一个问题：**这个业务概念是否与这个标准对象的本来用途干净契合？**如果是，我就倾向于用标准对象。
经销商是一家与我们有业务关系的公司，所以客户是干净契合的。我不介意用户把一家公司叫经销商，另一家叫供应商，再一家叫零售合作伙伴，还有一家叫客户。这些是业务角色，它们不需要四个物理对象。**不同的业务名称并不自动意味着不同的数据结构。**一个类型、一个记录类型或一个关系就可以承载这种差别。
这个测试反过来也适用。在第 1 章里，我给你留了一个问题：一个客户的业务有很多个配送地点。每个地点应该是一个客户（Account），还是一个自定义对象？
客户能给你很多东西。你会得到地址字段，以及所有已经预期使用客户地址的东西：报表、地图、集成。但你也会得到它的开销：大量字段、共享、层级、所有权，挂在客户身上的一切，而其中大部分都和一个单独的地址无关。仅仅为了一个备用地址，你就要背上一大堆用不上的重东西。
而一个自定义对象，作为客户的子对象，可以很轻量：只有地址字段，代表一个我们要送货的地方，有它自己的生命周期，我可以独立地控制它。
所以这是一种平衡：**你承担的分量，对比你得到的价值。**如果我需要的只是一个有自己生命周期的地址，那我就会用自定义对象。
个案下面的子问题也是一样。如果每个子问题真的就是一个个案，由坐席处理，有自己的状态和服务级别，那就用模块 2里的上级个案（Parent Case）把它们嵌套起来。但如果它只是一个没人会当作个案来处理的检查清单条目，一个完整的个案就会带着很多永远用不上的东西，而一个简单的自定义子对象可能更轻。不是因为自定义更干净，而是因为含义不同，或者分量不对。
标准对象自带包袱
Section titled “标准对象自带包袱 ”当你选择一个标准对象时，你选择的不只是它的字段。你选择的是 Salesforce 的各个产品已经理解的东西：报表、自动化、内置关系、产品功能、AppExchange 软件包，以及 Salesforce 接下来要构建的任何东西。这可能有巨大的价值。
标准对象也带着自己的主张：既有的行为、关系、安全方面的考虑，有时还有许可要求，以及你用不上的功能。所以“永远用标准对象”不是我的规则。我没有“永远”的规则。我有的是一种倾向：**当含义干净契合，并且围绕它的平台行为是在帮助设计而不是与之作对时，就用标准对象。**如果我花五年时间，让业务机会去表现得像一个并不是销售机会的东西，那么坚持用标准对象并没有给我带来任何好处。我只是在另一个方向上做了错误的妥协。
资产是个好例子
Section titled “资产是个好例子 ”资产是人们常常忽略的标准对象之一。我能给出的最简单的说法是：**它是客户拥有的一样东西。**也许是从我们这里买的，也许不是。我仍然在意放在客户现场的竞争对手的产品，因为我在维修它，或者想替换它，或者需要了解他们的装机情况。如果我没有先看看资产就创建了 Customer_Product__c，我就跳过了一个架构问题。资产不会自动胜出，但它值得被评估。
个人客户：这个人什么时候就是客户？
Section titled “个人客户：这个人什么时候就是客户？ ”在模块 2里，我们认识了个人客户：把客户和联系人合在一条记录里，用于身为个人的顾客。现在来做决定。
我的立场是：**对于 B2C，很难不用它们。客户和联系人开箱即带的东西实在太多，所以付出的成本和开销是值得的。而成本确实存在：存储大约是企业客户的两倍，一个打开后就关不掉的开关，而且有些外部许可不能使用它们。Partner Community 不能与个人客户一起使用（Experience Cloud User Licenses (opens in a new tab)，英文）。所以问题不是“我们的数据库里有没有人？”每个 org 里都有人。问题是“在这个业务里，这个人真的就是客户吗？”**联系人是一个人，并不会让它成为个人客户。决定这一点的是业务关系。
现在让我把一切都复杂化：许可
Section titled “现在让我把一切都复杂化：许可 ”到目前为止：找到概念，寻找最干净契合的标准对象，含义不契合时用自定义对象。现在是架构师的追问：**谁需要使用它？**你可以设计出一个漂亮的模型，然后发现需要这些数据的人里有一半没有你所选对象的许可。许可是数据模型的一部分。
三种内部许可
Section titled “三种内部许可 ”先从你自己的员工说起。在公司内部，有三种许可类型我希望每位架构师都烂熟于心，因为它们决定了每个用户能看到什么、能做什么，也就决定了你的数据模型可以依赖什么。
Sales Cloud（现在叫 Agentforce Sales）。这些用户拥有完整的 Salesforce 用户许可：标准 CRM 对象，以及任何标准或自定义应用。也就是在客户和联系人之上，还有潜在客户、业务机会和预测，甚至还有个案：销售代表可以在打电话之前看到客户未结的个案。创建和运行市场活动还需要再加一样东西：Marketing User 功能许可。
Service Cloud（现在叫 Agentforce Service）。同样是 Salesforce 用户许可，只是为服务而配置。个案处于中心，在 Service Console 中处理：Service Cloud User 功能许可正是打开 Salesforce Console for Service 的那把钥匙。服务级别协议就在这里，通过权利（Entitlement）管理和里程碑来实现；Knowledge 也在这里登场，大多数版本要把它作为附加功能单独购买。
Platform（Salesforce Platform）。面向需要你的自定义应用、而不需要 CRM 的人。他们能使用客户、联系人、报表、仪表板、文档，以及 org 里的每一个自定义应用。他们用不了的是：预测、潜在客户、市场活动和业务机会。它更便宜，这正是那么多大型自定义应用都运行在它上面的原因，也正是它可能让你的数据模型栽跟头的原因。
| Sales Cloud | Service Cloud | Platform | |
|---|---|---|---|
| 用户许可 | Salesforce | Salesforce | Salesforce Platform |
| 用途 | 销售 | 支持客户 | 自定义应用 |
| 客户、联系人 | 是 | 是 | 是 |
| 潜在客户、业务机会、预测 | 是 | 是 | 否 |
| 个案 | 是，用于查看客户的个案 | 处于中心，在 Service Console 中 | 否 |
| 服务级别协议 | 否 | 是，权利和里程碑 | 否 |
| 自定义对象和应用 | 是 | 是 | 是 |
像架构师那样读这张表。如果有一大批用户用的是 Platform，那么任何把他们的工作放到业务机会上的设计，还没开始就已经坏了。如果高管需要 SLA 数字，他们所用的许可决定了他们能不能看到。这三种类型决定了行为。
当许可决定对象时
Section titled “当许可决定对象时 ”业务机会是我遇到最多的受害者。你在表里已经看到了：Platform 用户用不了它（Standard User Licenses (opens in a new tab)，英文），Customer Community 用户也不能使用它。于是需求看起来像业务机会，有人说“我们用业务机会吧”，然后我问谁需要访问。如果有一大批人用的是 Platform 或 Customer Community 许可，许可就不再是一个采购细节，而是一个架构约束，它通常会把设计推向自定义对象。
往上也是一样。我在课上会问：CEO 想要漂亮的仪表板，用 Sales 许可还是 Service 许可？Sales 用户可以看到销售对象，甚至个案，所以对于销售仪表板和未结个案数量，Sales 就够了。但一旦高管想要 SLA KPI（一个个案还有多久会违反服务级别），这些数据就在权利和里程碑里，而权利管理需要 Agentforce Service，也就是以前的 Service Cloud（Supported Editions for Service Features (opens in a new tab)，英文）。现在你就得升级高管们的许可了。倾听业务需求，并知道它所需的数据底下是哪种许可。
我把许可想象成体育场里的座位。大家看的是同一场比赛。如果我买了中间的贵座，我能近距离看到两支球队。如果我坐在角落的看台上，座位没有软垫，我得拿着望远镜看。
这就是外部许可，面向公司之外的人：登录 Experience Cloud 站点的客户和合作伙伴。有三种我希望你了解。
Customer Community：露天看台。为需要个案和知识库的大量外部用户而设计：比如一位查看自己支持个案进度的客户。座位价格大约是一半，可以发给数量庞大的用户。坐在上面你会失去什么？报表、仪表板，以及共享表：更高等级才有的基于角色的共享。它可以与个人客户一起使用。
Customer Community Plus：往下坐到大约一半的位置。Salesforce 把它描述为面向需要报表、仪表板和标准共享的外部用户的许可：比如一位要管理其他人访问权限、或者需要看到自己数据的客户。
Partner Community：坐得更近，面向企业对企业，可以访问销售数据。合作伙伴要跟进潜在客户和业务机会：他们登记商机，并和你一起开展市场活动。这是能触及销售对象的那种外部座位。有一个问题：它不能与个人客户一起使用（Experience Cloud User Licenses (opens in a new tab)，英文）。
错误在于按照每个人都有贵票来设计，然后在实施时发现，你的大多数用户都进不了你放他们数据的那个区域。这时你有三个选择：买不同的座位，把体验挪个地方，或者重新设计模型。三者都是架构。
付费方式会改变设计
Section titled “付费方式会改变设计 ”还有一个人们会忘记的问题：**这些用户会如何登录？**外部许可有两种形式。按成员计费：按用户付费，适合每天都登录的 500 个合作伙伴。按登录计费：每月购买一定数量的登录次数，适合一年只登录几次的五百万客户。同一天内多次登录仍然只算一次登录（Experience Cloud User Licenses (opens in a new tab)，英文）。
所以当有人说“我们要建一个客户门户”时，我接下来的问题不是用哪个模板，而是：客户是谁，有多少，多久来一次，他们需要什么数据，他们被允许用这些数据做什么？
当许可塑造模型时
Section titled “当许可塑造模型时 ”有时许可不只是决定用哪个对象；它会让整个模型变形。有些平台许可把用户限制在一个自定义应用里，最多十个自定义对象（例如 Lightning Platform – One App；Standard User Licenses (opens in a new tab)，英文）。
在早年的一个项目里，客户是一家大型专业服务和建筑公司，我们要为全体员工构建一个类似 LinkedIn 的东西：每个人的职位、技能、证书、语言和项目，这样他们就能找到在某个国家持证的桥梁建造者。如果没有限制，我会建用户职位、用户技能、用户证书、用户语言和用户项目对象，再加上证书和项目的参考列表。在十个对象的许可下，而且被告知不要把它们全用光，这就不可能了。于是它变成了一场猜歌名游戏：我最少用几个对象能把它建出来？答案是两个。一个参考对象，每种列表（职位、技能、证书、语言、项目）各有一个记录类型；再加一个用户属性对象，带着对应的记录类型，指向它。
这不是最优的模型。做报表很痛苦，我也更希望它干净一些。但许可只允许这样。我把这类对象叫作瑞士军刀对象：把这个模式放在口袋里备用，当限制让你毫无余地时，就打破玻璃，改用记录类型来区分。只是要知道你在交换什么。每个记录类型需要不同的权限，可能最后还是会逼你把对象拆开。
用户不再只是人
Section titled “用户不再只是人 ”还有一个许可问题变得很重要：那些不是人的东西怎么办？集成有身份。智能体有身份。Salesforce 现在有一种用于系统间集成的 Salesforce Integration 许可：只能用 API，不供人使用，每个 Enterprise、Unlimited 和 Performance Edition 的 org 都包含五个（Standard User Licenses (opens in a new tab)，英文）。所以不要只问哪些用户需要访问。要问哪些身份需要访问：一个人、一个客户、一个合作伙伴、一个集成、一个智能体。然后再问每一个需要看到什么、做什么。
**考试之外：AI 改变了什么。**随着智能体成为数据的又一个消费者和创建者，对象选择和许可就不再只关乎人看的界面。要知道智能体以哪个身份运行，这个身份能触及什么，以及模型是否把它需要的数据放在了它无法使用的对象或权限后面。
Steve Trucking：一个简单的，一个难的
Section titled “Steve Trucking：一个简单的，一个难的 ”Steve Trucking 与零售合作伙伴合作。零售合作伙伴是什么？一个企业。简单：客户（Account）。我不会因为有人用了“合作伙伴”这个词就创建 Retail_Partner__c。
再看收货人，也就是接收冰箱的那个人。联系人？个人客户？还是别的什么？每年一百万位新收货人，而他们是零售合作伙伴的客户，不是我们的。在理解关系、访问和规模之前，我正是不想贸然选定对象的那类问题。我们会在第 1 部分的检查点上做出决定。
架构师在这里决定什么
Section titled “架构师在这里决定什么 ”- 一个业务概念是与某个标准对象的本来用途干净契合，还是它的含义或分量有所不同。
- 不同的业务标签是不同的实体，还是同一个实体的不同角色。
- 在计划的许可下，每一个需要这些数据的人、外部用户、集成和智能体，是否都能访问所选的对象。
- 用户数量和登录模式（按成员计费还是按登录计费）如何塑造许可和模型。
- 什么时候一个许可限制足以证明一个不那么理想的模型是合理的，以及这种交换在报表和权限上要付出什么代价。
重点不是标准对象好、自定义对象坏。重点是这个选择有后果，而且有时决定它的根本不是那个名词，而是需要使用它的人，以及机器。
- Salesforce Help，Standard User Licenses (opens in a new tab)（英文），查阅日期 2026-10-02，再次查阅 2026-10-12：Platform 用户无权使用预测、潜在客户、市场活动和业务机会；一个最多包含 10 个自定义对象的自定义应用；每个 Enterprise Edition 的 org 包含五个 Salesforce Integration 许可。
- Salesforce Help，Experience Cloud User Licenses (opens in a new tab)（英文），查阅日期 2026-10-02，再次查阅 2026-10-12：Partner Community 不能与个人客户一起使用；Customer Community Plus 用于报表、仪表板和标准共享；同一天内多次登录只算一次。
- Salesforce Help，Supported Editions for Service Features (opens in a new tab)（英文），查阅日期 2026-10-02，再次查阅 2026-10-12：服务级别协议（权利管理）随 Agentforce Service 提供；在大多数版本中，Knowledge 需要额外付费。
- Salesforce Help，Available Feature Licenses (opens in a new tab)（英文），查阅日期 2026-10-12：Service Cloud User，“Access the Salesforce Console for Service”（访问 Salesforce Console for Service）；Marketing User 用于创建和管理市场活动。