Salesforce 共享模型是贵组织提供安全应用程序数据访问能力的基本元素。因此，正确构建共享模型以满足您当前和未来的数据访问要求至关重要。在本文档中，我们将回顾数据可访问性组件、共享模型用例和真正的客户共享解决方案，并将提供一些故障排除指南。

本文档面向高级系统管理员和架构师。要理解这些概念，您必须对 Salesforce 安全和共享模型拥有实际 Knowledge。本指南的先决条件是：

• Salesforce 帮助：共享设置
• Trailhead 模块：数据安全
• 设计企业级的记录访问权限
• Salesforce 精心设计 - 安全

本指南侧重于用于控制对标准和自定义对象的记录级访问权限的主要功能。本指南未涵盖的主题包括：

• 文件夹访问权限
• 内容访问权限
• Chatter 访问权限
• Knowledge 库访问权限
• 意见、问题/答案访问权限
• 移动数据可访问性

记录级安全性允许您授予用户对一些对象记录的访问权限，但不允许访问其他对象记录。与大多数应用程序一样，数据访问从用户开始。应用程序在提供访问权限之前必须知道用户是谁。对于 Salesforce，有不同类型的用户，有时，访问权限级别因类型而异。我们将在这里关注对数据访问有重大影响的有趣属性，而不是查看每种许可证类型的每个属性。记录所有权和完全访问权限是同义词，可以互换，并为用户提供对记录的最高级别的访问权限。

高用量用户

高用量用户（包括拥有客户社区、高用量客户入口网站和验证网站许可证类型的用户）不使用共享模式，因为他们的许可证类型不支持角色。这些许可证有自己的共享模式，它通过用户（持有许可证）与客户和联系人查找上的数据之间的外键匹配来工作。管理员可以创建共享集或共享组，以授予高用量用户对记录的访问权限。

Chatter Free 和 Chatter External 许可证

Chatter Free 和 Chatter External 许可证不遵循标准共享模式。这些许可证无权访问 CRM 记录（标准或自定义对象）和内容功能，并且不支持角色，因此没有共享。

对于本文档的剩余部分，我们假设 Salesforce 用户类型使用完全共享模式。有关每种可用许可证类型的更多信息，请参阅用户许可证。

简档和权限集

简档和权限集通过确定用户可以看到的数据类型以及他们是否可以编辑、创建或删除记录来提供对象级安全性。对于每个对象，“查看所有”和“修改所有”权限会忽略共享规则和设置，允许管理员快速授予对与组织内给定对象关联的记录的访问权限。通常，这些权限是“查看所有数据”和“修改所有数据”管理权限的首选替代权限，允许用户查看或修改所有应用程序和数据。

简档和权限集还控制字段级安全性，这将确定用户可以访问的每个对象中的字段。例如，一个对象可以有 20 个字段，但可以设置字段级安全性来防止用户看到 20 个字段中的 5 个。

我们强烈建议您使用权限集和权限集组而不是简档来管理用户的对象权限。因为您可以重复使用更小的权限集构建块，所以您可以避免为每个用户和作业功能创建几十个甚至几百个简档。

记录所有权和队列

每个记录必须由单个用户或队列拥有。根据所有者简档的对象设置，所有者有权访问记录。例如，如果所有者的简档拥有对象的创建和读取权限，但没有编辑或删除权限，所有者可以为对象创建记录并查看新记录。但是，所有者将无法编辑或删除记录。层次结构（角色或区域）较高的用户继承与其下属相同的标准对象的数据访问权限。如果下属具有只读访问权限，角色层次结构中位于下属之上的用户也将具有只读访问权限。此访问权限适用于用户拥有的记录，以及与用户共享的记录。

队列帮助您确定优先级、分发记录并将其分配到共享工作量的团队。队列成员和角色层次结构中较高的用户可以从列表视图访问队列，并获取队列中记录的所有权。

如果单个用户拥有超过 10,000 条记录，作为最佳实践：

• 所有者的用户记录不应在角色层次结构中保留角色。

• 如果所有者的用户记录必须包含角色，请将角色放在角色层次结构自己的分支的层次结构顶部。

有关更多信息，请查看Salesforce 架构良好 - 可靠。

组织范围的默认设置

组织范围内的共享设置指定用户对彼此记录的默认访问权限级别。您可以使用组织范围内的共享设置将您的数据锁定在最严格的级别。使用其他记录级安全和共享工具，有选择地授予其他用户访问权限。例如，用户拥有读取和编辑业务机会的对象级权限，组织范围的共享设置为只读。默认情况下，这些用户可以读取所有业务机会记录，但不能编辑任何业务机会记录，除非他们拥有该记录或被授予其他权限。

组织范围的默认设置可以从一个设置更改为另一个设置（专用更改为由父级控制，然后改回专用）。但是，这些更改需要共享重新计算，并且取决于数量，可能会导致处理时间较长。

仅对于自定义对象，您可以配置使用层次结构授予访问权限设置。如果未选中（默认选中），角色层次结构中较高的用户将无法继承访问权限。此设置在组织范围的默认设置中找到。

角色层次结构

角色层次结构表示用户或用户组需要的数据访问级别。角色层次结构确保经理始终可以访问与其员工相同的数据，而不管组织范围内的默认设置如何。角色层次结构不必完全匹配您的组织图表。相反，层次结构中的每个角色应代表用户或用户组需要的数据访问级别。

在 Spring ’21 或更高版本中创建的 Salesforce 组织中，您最多可以创建 5,000 个角色。在 Spring ’21 之前创建的组织中，您最多可以创建 500 个角色，并且可以联系 Salesforce 客户支持来增加此限制。作为最佳实践，将内部角色的数量保持在 25,000，并将外部角色的数量保持在 100,000。

作为最佳实践，将角色层次结构保持在层次结构中不超过 10 个级别的分支。

当用户的角色发生变化时，系统会评估任何相关的共享规则，以根据需要更正访问权限。同一角色中的对等项不保证他们可以访问彼此的数据。

建模角色层次结构首先要了解组织的结构。这通常是从头开始理解经理的范围。CEO 监督整个公司。CEO 通常拥有直接下属，然后可以按业务部门（销售或支持）或地理区域（EMEA、亚太地区）细分。然后，该人员拥有可进一步细分的直接下属，以此类推。虽然这听起来非常像人力资源组织结构图，但在对数据访问进行建模时，应重点关注数据可访问性，并考虑人力资源报告。

叠加始终是层次结构中的棘手部分。如果他们在自己的分支机构，他们需要共享规则、团队或区域管理来获得所需的访问权限。如果将它们折叠到层次结构中，可能会涉及报告问题。

花时间设置角色层次结构非常重要，因为这是共享模式的基础方面之一。

公用小组

公用小组是单个用户、角色、区域等的集合，它们都有一个共同的功能。公用小组可以包括：

• 用户
• 客户入口网站用户
• 合作伙伴用户
• 角色
• 角色和内部下属
• 角色、内部和入口网站下属
• 入口网站角色
• 入口网站角色和下属
• 区域
• 区域和下属
• 其他公用小组（嵌套）

小组可以嵌套（小组 A 嵌套到小组 B 中），但嵌套不要超过五个级别。由于小组成员关系计算，嵌套会影响小组的维护和性能。作为最佳实践，将组织的公用小组总数保持在 100,000 个。

基于所有人的共享规则

基于所有者的共享规则允许对组织范围的默认设置和角色层次结构进行例外，这些设置和角色层次结构授予其他用户对不属于他们的记录的访问权限。基于所有人的共享规则仅基于记录所有人。

基于联系人所有者的共享规则不适用于专用联系人或未与客户关联的联系人。

每个对象的共享规则总数限制为 300。

基于条件的共享规则

基于条件的共享规则提供对基于记录字段值的记录的访问权限（条件）。如果满足条件（一个或多个字段值），则为规则创建共享记录。记录所有权不是考虑因素。

每个对象基于条件和来宾用户共享规则的限制是 50。

来宾用户共享规则

来宾用户共享规则是一种特殊类型的基于条件的共享规则，用于向未经身份验证的来宾用户授予记录访问权限。每个对象基于条件和来宾用户共享规则的限制是 50。

**警告：**来宾用户共享规则类型向没有登录凭据的来宾用户授予访问权限。通过创建来宾用户共享规则，您可以允许任何人立即无限制地访问符合共享规则条件的所有记录。为了保护您的 Salesforce 数据并让您的来宾用户访问他们需要的内容，请考虑创建这种类型的共享规则的所有用例和影响。实施您认为适合数据敏感性的安全控制。Salesforce 不对基于此默认设置更改的数据暴露给未经身份验证的用户负责。

手动共享

有时，无法定义需要访问特定记录集的一致用户组。记录所有人或其他具有足够权限的用户（例如系统管理员）可以使用手动共享，以向没有任何其他访问权限的用户授予读取和编辑权限。手动共享不像组织范围的共享设置、角色层次结构或共享规则那样是自动的。但它让记录所有者可以灵活地与必须查看记录的用户共享记录。

当记录所有人更改时，或者当授予的共享访问权限未授予超出对象组织范围内的共享默认访问权限级别的附加访问权限时，手动共享将被删除。这也适用于以编程方式创建的手动共享。

手动共享记录定义为行原因设置为手动共享的共享记录。

即使共享记录是以编程方式创建的，也可以通过对象页面布局上的**共享**按钮编辑和删除行原因设置为手动共享的所有共享记录(标准和自定义对象)。

团队

团队是一组共同处理客户、销售业务机会或个案的用户。记录所有者可以为他们拥有的每个记录构建团队。记录所有人添加团队成员，并指定每个团队成员对记录的访问权限级别。一些团队成员可以具有只读访问权限，而其他人具有读/写权限。

只有所有人、层次结构中较高的人员和管理员，才可以添加团队成员并为成员提供更多访问权限。具有读/写访问权限的团队成员可以添加另一个已经拥有团队关联记录访问权限的成员。团队成员不能为他们提供额外的访问权限。

在应用程序中创建团队成员会创建两个记录：团队记录和关联的共享记录。如果您以编程方式创建团队成员，您必须管理团队记录和关联的共享记录。每个记录（客户、业务机会或个案）只有一个团队。如果需要多个团队，根据您的特定需求，考虑区域管理或编程共享

区域层次结构

在使用 Enterprise 区域管理时，您可以设置区域层次结构，以显示模型的区域结构并作为其主要交互点。如果启用 Enterprise 区域管理，您必须管理角色层次结构和区域层次结构。有关更多信息，请查看 Salesforce 帮助中的企业区域管理。

Apex 受管共享

Apex 受管共享(也称为编程共享)允许您在数据访问要求无法通过任何其他方式满足时使用代码来构建复杂和动态的共享设置。

如果您以编程方式创建共享记录，并使用现成的行原因(手动共享),则可以使用应用程序中的**共享**按钮维护此共享记录。共享记录受手动共享行原因的所有规则的约束，例如在所有人转移时删除。

您还可以为自定义对象创建自己的 Apex 共享原因，以跟踪包含用户或用户组的记录的原因，并简化更新和删除共享记录所需的编码。

有关更多信息,请在考虑使用编程共享之前审查使用 Apex 共享记录。

限制规则

在数据访问配置中，您可能想要阻止用户查看可能包含敏感数据或根本不是他们工作所必需的记录。您可以使用限制规则，以允许用户仅访问满足您指定条件的记录。在限制规则应用于用户时，通过组织范围的默认值、共享规则和其他共享机制授予用户访问权限的记录将按您指定的条件进行筛选。限制规则的工作方式与本主题中讨论的共享组件相反；它们不向用户开放访问权限，而是进一步限制它。

限制规则对自定义对象、外部对象、合同、事件、任务、出勤表和出勤表条目可用。在 Enterprise 和 Developer Edition 中，每个对象最多可以创建两个活动限制规则，在 Performance 和 Unlimited Edition 中，每个对象最多可以创建五个活动限制规则。限制规则应用于以下 Salesforce 功能：

• 列表视图
• 查找
• 相关列表
• 报表
• 搜索
• SOQL
• SOSL

隐式共享

隐式共享是自动的。您既不能关闭也不能打开它，它是应用程序的本机。换句话说，隐式共享不是可配置的设置；但是，对于任何架构师来说，理解它都很重要。父级隐式共享是在用户有权访问该客户的子级业务机会、个案或联系人时提供对父级记录的访问权限（仅限客户）。Salesforce 的数据访问策略声明用户是否可以看到联系人（或业务机会、个案或订单），然后用户隐式地可以看到关联的客户。子隐式共享是向客户所有人提供对客户子记录的访问权限。此访问权限由所有者在角色层次结构中的角色定义。子级隐式共享仅适用于联系人、业务机会和个案对象（客户的子级）。对于创建角色时的每个子对象，可以提供的访问级别是查看、编辑和没有访问权限。通过设置为查看，客户所有人可以隐式查看关联的对象记录（联系人、业务机会或个案）。通过设置为编辑，客户所有人可以隐式修改关联对象（联系人、业务机会或个案）。

隐式共享不适用于自定义对象。

没有适合所有 Salesforce 组织的共享模式。在尝试构建最佳共享模式时，每个组织都有不同的要求和挑战。使用最合适的数据访问组件以满足组织的共享要求至关重要。以下情况是尝试构建共享模型时的常见挑战。

• 角色层次结构会发生什么？

  • 如果您也在使用区域层次结构，则角色层次结构不会发生任何变化。但是，如果您同时使用基于区域的预测和基于角色的预测，则必须管理两个层次结构。在这种情况下，我们建议您使用角色层次结构来建模人力资源报告结构，然后使用区域层次结构来建模实际的销售层次结构。区域层次结构最适合对矩阵报表结构进行建模，其中某人可以向多个经理报告。

    如果您未同时使用基于区域的预测和基于角色的预测，则仅可将区域层次结构用作销售层次结构。在这种情况下，最好尽可能简化或扁平化层次结构。

    我们不建议使角色层次结构和区域层次结构相同，因为这会导致不必要的共享活动。

• 您仍然可以使用团队吗？

  • -是的但是，如果您可以在区域层次结构中满足访问要求（例如叠加），最好在那里完成，而不是使用团队。您已经在维护多个层次结构（角色和区域），因此为了尽可能简化，只有在没有其他现有共享组件可以满足要求时，才实施团队。

• 重新调整和重新分配

  • 有两种类型的更改发生 - 角色、团队或区域的成员关系，以及层次结构。成员关系变更通常每天发生，甚至每小时一次。层次结构（重新调整）变化通常不太频繁（每季度、半年或每年），并且可能需要大量资源。必须考虑更改的数量以及每个更改将导致的级联更改的数量。作为经验法则，结构变化不超过每季度一次，并且所有高用量变化（批量或批量变化）都得到很好的计划、测试和协调。

• 大数据量

  • 无论您是为初始推出建模还是计划重新校准更改，您都必须认真考虑数据量。有一些阈值会使性能成为一个因素，因此强烈建议在生产之前在 Sandbox 中测试您的更改。此测试还将为您提供更改需要多长时间的基准。

    如果您的客户超过 200 万个，并且实施了团队或 Enterprise Territory Management，您尤其必须关注绩效。这些是复杂的共享模型组件，可以生成大量共享记录，从而完成长时间运行的事务。

• 延迟共享计算

  • 如果您有一个使用共享的对象，并且有大量记录（例如超过 200 万个客户），并且您必须进行批量更改（例如需要层次结构更改的季度调整），那么 Salesforce 客户支持可以启用一个功能来延迟自动共享计算。在本机，对角色层次结构、区域层次结构、小组、共享规则、用户角色、团队成员关系或记录所有权的每个个人更改都可以启动自动共享计算。当进行批量更改时，它会导致开始许多自动共享重新计算。通过暂时暂停这些重新计算，您可以进行更改，然后一次完成共享计算。这种方法通常对于批量更改更有效，性能更好。

• 数据和所有权偏差

  • 数据偏差被定义为一些具有许多子记录的父记录。当一些客户拥有多个联系人、业务机会或个案时，这些偏差会真正伤害您。我们开始看到性能下降的比率是 1:10000。作为最佳实践，请保持比率尽可能接近该比率（越低越好）。

    所有权偏差与数据偏差相似，只是我们指的是单个用户、角色或组拥有对象的多个记录。与数据偏差一样，这些偏差也会导致事务运行时间过长，从而在发生变化时导致性能下降。所有人与记录数量的推荐比率也是 1:10000。

    如果单个用户拥有超过 10,000 条记录，作为最佳实践：

    • 所有者的用户记录不应在角色层次结构中保留角色。

    • 如果所有者的用户记录必须包含角色，请将角色放在角色层次结构自己的分支的层次结构顶部。

• 客户层次结构对数据访问的影响

  • 很多人在实施客户层次结构时会做出错误的假设。他们假设可以访问父客户的用户也可以访问子客户。两个记录之间只有父/子关系这个简单事实不会提高访问权限。虽然角色层次结构和区域层次结构以这种方式工作，但客户层次结构并非如此。

在您完成共享模式架构后，您可能会遇到用户为何可以查看或不可以查看记录的问题。通常，您不会听到用户何时可以看到他们不应该看到的东西，但如果需要，有一种方式可以查看有权访问记录的每个用户及其原因。

更困难的挑战（可能更常见）是用户为何看不到记录。您构建的安全层决定了您的起点。如果您非常了解共享模式，那么您可能知道哪个组件应该提供访问权限，并且可以从那里开始。但如果您不太熟悉共享模式，请从角色层次结构开始，并深入了解每个层，以确定哪个层应提供访问权限。以下是故障排除流。

1. 请确认用户拥有访问对象的权限。
2. 确定看不到记录的用户角色，并记录下来。
3. 确定记录角色的所有者，并记录下来。
4. 查看角色层次结构，并确认这两个角色位于两个不同的分支中（应该是）。
5. 现在，您必须查看对象的共享规则，并确保没有授予用户访问权限的规则。如果需要，也可以查看公用小组。也许用户被排除在存在共享规则的小组之外，或者创建新的共享规则来授予用户访问权限是否合理？此选择取决于您尝试维护的架构，并适用于基于所有者的共享规则和基于条件的共享规则。
6. 如果您使用团队，此用户是否应该是该记录的团队？团队如何维护，错过是如何发生的？
7. 如果使用手动共享，用户可能会因为记录所有人更改而失去访问权限。当所有权变更时，手动共享会被删除。手动共享也可以使用共享按钮删除。
8. 如果您正在使用 Enterprise 区域管理，其中一个区域是否缺少用户？区域成员关系在哪里保留，错过是如何发生的？或者，记录可能未分配到用户是成员的区域。
9. 如果您正在创建编程共享，并且有在代码中创建共享的条件，请查看代码以了解忽略此用户的原因。