01 理解许可如何工作（Understand How Licenses Work）
本单元打好基础：用办公楼和租约类比解释什么是 Salesforce 许可，定义三种设置许可（平台、用户、权限集），最后展示它们如何被打包进你实际购买的版本和附加组件。
学完本单元，你将能够：
- 解释什么是 Salesforce 许可；
- 定义平台许可、用户许可和权限集许可；
- 描述平台、用户、权限集许可与版本和附加组件的关系。
什么是许可？（一）：办公楼类比
Salesforce 常被比作一座大型办公楼，客户 Org 是楼里的租户。每个 Org 都运行在共享的 Salesforce 技术基础设施上，拥有仅自己用户可访问的安全私有空间。
沿用这个类比，Salesforce 许可就像物业管理方和租户之间的租约。更准确地说，一个许可定义（license definition）是对你可用的 Salesforce 功能和服务的一份元数据描述——正是它让你的"办公室"变得可用。
什么是许可？（二）：许可涵盖什么
许可定义描述两个层面的功能：面向整个 Org 的，以及面向 Org 中单个用户的。许可是 Salesforce 与某个客户之间的具体协议，定义了该客户 Org 的功能。一个 Org 通常有多个许可，共同构成它所有可用的功能和服务——包括开始和结束日期、可访问 Salesforce 的用户数、Org 可创建的自定义对象数等。
什么是许可？（三）：供给（Provisioning）
供给（Provisioning）是 Salesforce 在后台运行的流程，用来激活你的许可、启用功能——就像租户和物业握手、交首期租金、拿到办公室钥匙。它在以下情况自动发生：初次购买建立 Org、购买升级或附加组件、补丁版本改变了许可定义。
一个重要的细节：供给只适用于生产 Org。沙盒（沙盒是测试用的 staging 环境）需要把许可变更单独推送过去；Demo、Developer、Scratch、Trial Org 则不做供给。可以通过刷新沙盒或使用 Match Production License 工具更新沙盒。
许可类型（一）：全局图景
你肯定熟悉 Professional、Enterprise、Unlimited 等版本——它们捆绑功能以应对不同业务需求。你还知道附加组件（add-ons）和权限与偏好（perms & prefs）。这些怎么拼到一起？答案是：许可。
权限（perms）是元数据开关，控制对功能的访问（如 Lightning Experience、Chatter 和某些安全方面）；偏好（prefs）是客户可配置的设置（如时区、密码选项）。两者被打包进许可——平台许可定义整个 Org 的功能，用户许可定义单个用户的功能。
许可类型（二）：用户与权限集许可
作为管理员，你给每个用户分配一个用户许可，它决定用户能访问什么功能。一个版本或附加组件可以包含多种用户许可类型——例如 Sales Cloud Enterprise 包含 Full CRM 用户许可（CRM 访问）和 Chatter Free 许可（只访问 Chatter）。
很多产品还包含权限集许可（permission set licenses）。和用户许可一样，它定义用户级功能；但用户只能有一个用户许可，却可以分配多个权限集许可，用来增强用户许可所提供的功能。分配完用户和权限集许可后，还要通过配置文件和权限集来进一步细化访问（下一单元讲）。
许可类型（三）：三种设置许可
平台许可、用户许可和权限集许可统称为设置许可（settings licenses），因为它们携带的是设置——控制功能的权限和偏好。平台许可作用于 Org 级，用户许可作用于单个用户，权限集许可给用户叠加额外能力。
一个有用的细节：有些产品不提供用户许可。例如 Heroku 只创建平台许可、没有用户许可，因为它的产品在平台（Org）级别定义功能，而非用户级别。
版本和附加组件呢？（一）：产品许可
作为客户，你不直接购买单个权限、偏好，也不买单个平台/用户/权限集许可。你买的是产品许可（product licenses）：版本（editions）和附加组件（add-ons）。它们以不同组合打包平台、用户和权限集许可，把功能整理成易选择的功能套件。
回到租约类比：设置许可就像租约里的个别条款（如"30 层 1–12 号房"），而版本或附加组件就像整份租约文件，把条款和租约总则串在一起。
版本和附加组件呢？（二）：一个版本 + 可选附加组件
每个 Org 有且只有一个版本，由 Org 的版本许可决定——它是一组平台许可和用户许可，提供激活 Org 所需的全部功能。一个 Org 可以有多个合同，但都通过这一个版本许可授权用户访问；它不能同时通过两个版本许可授权。附加组件是可选补充，和版本一样可以包含平台和用户许可；一个 Org 必须有版本，但可以有任意多个附加组件，也可以一个都没有。
版本和附加组件呢？（三）：Ursa Major 示例
用 Maria Jimenez（Ursa Major Solar 管理员，约 200 名员工）的例子来具体化。Ursa Major 购买 Service Cloud 的 Enterprise 版本，并随版本购买 100 个 Full CRM 用户许可给 100 名员工使用 Service Cloud CRM。
Ursa Major 还想用 Salesforce Einstein 的客服 AI 功能，于是购买 Service Cloud Einstein 作为附加组件。该附加组件包含 Service Cloud Einstein 权限集许可。只有 10 名客户经理需要 Einstein，所以只买 10 个 Service Cloud Einstein 权限集许可。
上图展示了 Enterprise 版本（100 个用户许可）+ Einstein 附加组件（10 个权限集许可）的组合。
02 给用户所需的功能（Give Users the Functionality They Need）
本单元转向单个用户。我们看权限和偏好如何实现，定义配置文件（profiles）和权限集（permission sets）这两个管理员用来定制访问的工具，最后展示许可、配置文件和权限集如何共同决定每个用户能做什么。
学完本单元，你将能够：
- 解释权限和偏好在 Org 级和用户级如何实现；
- 定义配置文件和权限集；
- 描述管理员如何用配置文件和权限集控制用户对功能的访问。
幕后：权限与偏好（一）：从何而来
权限和偏好是定义谁能访问哪些产品功能的元数据设置。它们从哪来？Salesforce 的开发者构建新功能时会创建新的权限和偏好。创建后，开发者要么把它们加入现有许可（如果新功能与现有功能相关），要么创建新许可。记住：偏好是客户可以开关的设置。
幕后：权限与偏好（二）：如何实现
权限和偏好在两个层面出现。平台级的权限和偏好在平台许可里，对整个 Org 开关；用户级的权限和偏好在用户许可和权限集许可里，作用于单个用户。二者结合，就决定了某个用户可用的功能。
配置文件与权限集（一）：为什么两者都用
每个用户被分配一个用户许可，它设定了"天花板"——用户可能拥有的最大功能。但相似角色的用户职责各不相同：有的只读记录，有的创建删除记录，有的创建新对象。Salesforce 不会为每种变化都出一个许可，而是给管理员工具去定制访问。配置文件（profile）定义基线，权限集（permission set）为特定场景叠加额外功能。
上图说明每个用户被分配一个用户许可、一个配置文件，可能还有一个或多个权限集。
配置文件与权限集（二）：管理员如何使用
配置文件设每个用户的基线，权限集补充基线。因为权限集可以为特定场景授权（不论用户的主要岗位），所以能帮你减少需要创建的独特配置文件数量，也避免配置文件里塞满权限。
Maria 的例子很具体：她给几个用户分配 Service User 配置文件（可读、创建、编辑案例）；只有其中部分用户需要删除和转移案例，于是她创建 Delete And Transfer Cases 权限集，只分配给需要额外功能的用户，而不是再建一个配置文件。
整合（一）：全景
影响用户功能访问的变量很多。看 Ursa Major 的完整图景：高管购买 Service Cloud Enterprise + Service Cloud Einstein 附加组件，这些产品包含平台级偏好（管理员可开关）。管理员 Maria 按业务需求启用或禁用这些偏好。然后，为每个要使用 Salesforce 的员工创建用户，分配合适的用户许可和配置文件——配置文件不能超出用户许可所提供的功能。
整合（二）：完成设置
Maria 继续在用户层面叠加：按需分配权限集许可（比如给要用 Einstein 的客户经理分配 Service Cloud Einstein 权限集许可），再分配合适的配置文件来实际启用该功能；还分配普通权限集给需要超出配置文件能力的用户。最后每个用户调整自己的偏好来定制 Salesforce。
上图是 Maria 和两位同事在 Ursa Major Solar 办公室。理解了许可、配置文件和权限集之间的关系，你就知道什么决定了每个用户在 Org 里的功能。
03 跟进升级和附加组件（Keep Up with Upgrades and Add-ons）
最后一单元看随时间的变化：定义版本升级和附加组件，走一遍管理员在新许可到来时要做的操作，并展示许可变更后如何让沙盒 Org 与生产 Org 保持同步。
学完本单元，你将能够：
- 定义版本升级和附加组件；
- 解释为什么客户 Org 购买升级或附加组件后，管理员要更新配置文件和权限集；
- 解释客户如何让沙盒 Org 与生产 Org 保持同步。
关于版本升级和附加组件（一）：定义
首次注册 Salesforce 时，你选择当时最适合业务的版本。随着业务增长，可能需要更高级的功能。版本升级是 Org 迁移到更高的版本；附加组件则是在不改变版本的前提下，为 Org 补充额外的功能或服务。
关于版本升级和附加组件（二）：Ursa Major 示例
两种变化都出现在 Ursa Major 的故事里。升级：Ursa Major 一开始用 Enterprise，随业务增长可能迁移到 Unlimited Edition，以获得创建自定义应用的高级能力。附加组件：我们在第一单元见过，它用 Service Cloud Einstein 附加组件补充 Service Cloud Enterprise 版本——在底层版本不变的情况下增加 Einstein 能力。
升级和附加组件：管理员行动（一）：管理员做什么
升级或附加组件不是自服务的——它把新的平台、用户或权限集许可（或某种组合）投进你的 Org，需要有人把它们分配给正确的用户。作为管理员，你要审查新功能所需的权限，然后分配新的用户许可、权限集许可和配置文件，或者创建并分配新权限集、给现有权限集加权限。许可定义了什么可能，你的分配决定谁真正得到它。
升级和附加组件：管理员行动（二）：Maria 的 Einstein 实例
看 Maria 如何应对 Einstein 附加组件：她把 Service Cloud Einstein 权限集许可分配给 Lincoln 等客户经理（他们已有 Full CRM 用户许可，Einstein 权限集许可是在其之上的补充）。然后她把 Service Cloud Einstein 标准配置文件分配给同样的客户经理，这才是真正启用功能的一步。如果某些用户需要更多，她可以创建 Service Cloud Einstein 自定义配置文件，或建一个支持额外功能的权限集。
上图说明：一个用户许可 + 一个权限集许可 + 一个配置文件，共同定义用户的功能。
把许可变更推送到沙盒 Org（一）：为什么与何时
大多数版本允许创建沙盒——生产 Org 的副本，作为测试变更的 staging 环境。当你通过升级或附加组件变更许可时，通常希望生产 Org 和沙盒 Org 保持同步，所以要把许可变更推送过去。第一个选择是刷新沙盒：从源 Org（用于创建沙盒的生产 Org）更新沙盒的元数据；如果沙盒是克隆或用模板创建的，刷新还会更新数据。
把许可变更推送到沙盒 Org（二）：Match Production Licenses
如果你不想刷新沙盒，Salesforce 提供 Match Production Licenses to Sandbox 工具，把生产 Org 所有已供给的变更同步到沙盒，无需刷新。匹配会更新沙盒的许可数量以匹配生产、添加生产中有而沙盒没有的许可、删除沙盒中有而生产没有的许可——是一种精确对齐许可的方式。
把许可变更推送到沙盒 Org（三）：记住它们是独立的
收尾前一个提醒：沙盒和它对应的生产 Org 像两个独立 Org 一样运作。如果你在刷新沙盒之后在生产 Org 创建了新对象，那些对象要等下次刷新才会同步进沙盒；反过来，你在沙盒里创建的任何东西也不会自动推到生产 Org。把沙盒同步当作你控制的显式步骤，而不是自动发生的事。