精通 Salesforce 共享规则：构建可扩展的数据访问控制模型

十一月 18, 2025

背景与应用场景

作为一名 Salesforce 架构师，我工作的核心之一是设计一个既安全又高效的数据访问模型。在 Salesforce 平台中，数据可见性是整个安全架构的基石。这个模型的起点总是最具限制性的设置，即 Organization-Wide Defaults (OWD, 组织范围默认设置)。OWD 决定了用户对他们不拥有的记录的默认访问级别。例如，如果我们将 Opportunity 对象的 OWD 设置为 "Private"，那么默认情况下，用户只能看到自己拥有的商机记录。

然而，在现实的商业场景中，这种严格的隔离是远远不够的。团队协作是常态，跨部门、跨区域的数据共享需求无处不在。这时，Sharing Rules (共享规则) 就成为了我们扩展数据访问权限的关键工具。它们允许我们有选择性地、自动地向特定用户或用户组授予对记录的访问权限，从而打破 OWD 带来的限制。

典型的应用场景包括：

区域团队协作

一家全球性公司，其销售团队按地理区域划分（如北美团队、亚太团队）。虽然每个销售人员只拥有自己跟进的客户 (Account)，但区域销售总监需要查看其整个区域内所有客户的数据以进行战略规划。通过创建基于所有者角色的共享规则，我们可以轻松地将北美团队成员拥有的所有客户记录共享给整个“北美销售团队”这个 Public Group (公共小组)。

跨职能项目支持

当一个销售订单 (Order) 的金额超过特定阈值（例如 100 万美元）时，公司的法务团队和财务团队需要介入审查。这两个团队的成员并不拥有这些订单记录，但他们需要临时的读取甚至编辑权限。我们可以创建一条criteria-based sharing rule (基于条件的共享规则)，规则是：“当订单的 `Amount` 字段大于 1,000,000 时，将该记录的读/写权限共享给‘法务审批’和‘财务审批’公共小组”。

服务与支持协同

技术支持团队需要查看客户相关的、状态为“已签约”的合同 (Contract) 记录，以便在提供服务时了解客户的服务级别协议 (SLA)。销售人员拥有这些合同，但支持人员需要访问权限。一条基于条件的共享规则（例如 `Status = 'Activated'`）可以将这些合同记录共享给整个技术支持团队。

从架构师的视角来看，共享规则是连接“严格隔离”与“高效协作”之间的桥梁。它是一种声明式的、可预测的、可大规模部署的数据共享机制，是构建企业级 Salesforce 安全模型不可或缺的组成部分。

原理说明

要深入理解共享规则，我们必须先理解 Salesforce 的数据访问权限层次。它像一个层层放开的洋葱模型：

Organization-Wide Defaults (OWD): 这是最底层、最严格的基线。它定义了全局的默认访问级别（Private, Public Read Only, Public Read/Write）。
Role Hierarchy (角色层次结构): 它提供了一种垂直的、自上而下的访问权限扩展。管理者总是能访问其下属拥有的或被共享的所有数据。
Sharing Rules (共享规则): 这是我们今天的主角，它提供了一种横向的访问权限扩展。它能将记录访问权限授予给与记录所有者在角色层次上没有直接汇报关系的用户或小组。
Manual Sharing (手动共享): 用户可以手动将自己拥有的单个记录共享给其他用户或小组。这提供了最大的灵活性，但也是最不可预测和最难管理的。
Programmatic Sharing (Apex Managed Sharing): 开发者可以通过 Apex 代码来管理共享，适用于那些声明式工具无法满足的极其复杂的共享逻辑。

共享规则主要分为两种类型：

1. Owner-based Sharing Rules (基于所有者的共享规则)

这种规则基于记录的所有者。它的逻辑是：“如果一条记录的所有者属于某个公共小组、角色或区域 (Territory)，那么就将这条记录共享给另一个公共小组、角色或区域的成员”。这种规则非常适合基于团队或部门结构进行共享。

2. Criteria-based Sharing Rules (基于条件的共享规则)

这种规则基于记录本身的字段值。它的逻辑是：“如果一条记录的某些字段满足特定条件（例如，`Account.Industry = 'Technology'` 或者 `Case.Priority = 'High'`），那么就将这条记录共享给某个公共小组、角色或区域的成员”。这种规则极其强大和灵活，因为它实现了数据驱动的动态访问控制。

从技术底层来看，当一条共享规则生效时，Salesforce 会在后台为每个符合条件的记录和被共享的用户/小组组合，在被称为 Share Object (共享对象) 的特殊表中创建一条记录。例如，对于 Account 对象，对应的共享对象是 `AccountShare`。这条 `AccountShare` 记录明确定义了哪个用户/小组 (UserOrGroupId) 对哪个客户 (AccountId) 拥有什么级别的访问权限 (AccessLevel)，以及共享的原因 (RowCause)。正是这些 Share 表中的记录，构成了 Salesforce 精细化权限控制的核心。

作为一个架构师，理解 Share 对象的存在至关重要。因为当共享规则、所有权或记录数据发生变化时，Salesforce 需要在后台执行 Sharing Rule Recalculation (共享规则重算)，这可能会涉及对 Share 表进行大量的插入、更新或删除操作。在一个拥有数千万条记录和复杂共享模型的大型组织中，这个重算过程可能会对性能产生显著影响。

示例代码

虽然共享规则主要是通过 Salesforce UI 以声明方式配置的，但在某些复杂的业务场景下，我们需要通过代码来动态地控制共享。这就是 Apex Managed Sharing (Apex 管理的共享)。它允许我们使用 Apex 代码直接操作 Share 对象，以实现超越标准共享规则的逻辑。例如，一个项目管理应用，项目团队成员可能来自不同部门，且成员列表是动态变化的，这时就很难用标准规则来维护。

以下示例代码来自 Salesforce 官方文档，展示了如何使用 Apex 为一个特定的客户 (Account) 记录，编程方式地授予一个用户访问权限。

场景：当一个客户被标记为“战略客户” (`Type = 'Strategic'`) 时，需要自动将其读写权限授予给公司的首席战略官 (CSO)。假设我们已经通过 SOQL 查询获得了该客户的 ID (`accId`) 和 CSO 的用户 ID (`csoUserId`)。

// 1. 创建一个新的 AccountShare 对象实例
// AccountShare 是 Account 对象的标准共享对象
AccountShare strategicAcctShare = new AccountShare();

// 2. 设置需要被共享的 Account 记录的 ID
// 这是我们希望授予访问权限的目标记录
strategicAcctShare.AccountId = accId;

// 3. 设置将被授予访问权限的用户或小组的 ID
// 这里我们将其授予给首席战略官 (CSO)
strategicAcctShare.UserOrGroupId = csoUserId;

// 4. 设置访问级别
// 可选值为 'Read', 'Edit'。 'All' 仅适用于所有人共享。
// 我们在此授予读/写权限
strategicAcctShare.AccountAccessLevel = 'Edit';
strategicAcctShare.OpportunityAccessLevel = 'Read'; // 同样可以控制关联对象的访问级别

// 5. 设置 RowCause (共享原因) - 这是 Apex Managed Sharing 的关键
// 每个自定义的 Apex 共享原因都需要在对象的 Sharing Reasons 中预先定义
// 这有助于区分代码创建的共享和标准规则创建的共享，便于管理和调试
// 'Strategic_Account_Share__c' 是我们在 Account 的 Sharing Reasons 中自定义的原因的 API 名称
strategicAcctShare.RowCause = Schema.AccountShare.RowCause.Strategic_Account_Share__c;

// 6. 将创建的共享记录插入数据库
// 这个 DML 操作会使共享立即生效
try {
    Database.SaveResult sr = Database.insert(strategicAcctShare, false);
    if (sr.isSuccess()) {
        System.debug('成功为战略客户添加了 Apex Managed Sharing。');
    } else {
        for (Database.Error err : sr.getErrors()) {
            System.debug('为战略客户添加共享时出错: ' + err.getMessage());
        }
    }
} catch (DmlException e) {
    System.debug('DML 异常: ' + e.getMessage());
}

这段代码清晰地展示了通过 Apex 创建共享记录的五个核心步骤：实例化 Share 对象、设置目标记录 ID、设置目标用户/组 ID、定义访问级别，以及（最重要的）指定一个自定义的 `RowCause`。`RowCause` 允许管理员和开发者追踪共享的来源，对于维护一个复杂的共享模型至关重要。

注意事项

在设计和实施共享规则时，架构师必须充分考虑以下几点，以避免未来的性能瓶颈和管理噩梦。

1. 性能与扩展性

共享规则的重算是一个消耗资源的过程。每次更新共享规则、更改角色层次、或大规模更新记录所有权时，都会触发重算。在拥有海量数据的组织中，这可能导致暂时的性能下降或锁定问题。因此，应避免创建过于复杂或数量过多的共享规则。

2. OWD 是基础

永远记住，共享规则只能扩展访问权限，绝不能限制。如果一个对象的 OWD 是 Public Read/Write，那么为该对象创建任何共享规则都毫无意义，因为所有用户已经拥有了最高访问权限。

3. 避免所有权倾斜 (Ownership Skew)

当一个用户拥有超过 10,000 条某个对象的记录时，就会发生所有权倾斜。这会导致性能问题，因为任何涉及该用户的角色变更或共享规则变更，都需要处理大量的共享记录。架构上应尽量避免将大量记录分配给集成用户或单一队列，考虑将所有权分散。

4. Guest User (访客用户) 安全

对于社区或 Experience Cloud 站点中的访客用户，共享规则有严格限制。从 Winter '21 更新开始，你只能使用基于条件的共享规则（criteria-based）与访客用户共享记录，并且不能共享由访客用户拥有的记录。这是为了加强公共站点的安全性，必须严格遵守。

5. 维护的复杂性

随着业务发展，共享规则会不断累积。一个缺乏规划的共享模型会变得难以理解和维护。强烈建议使用公共小组 (Public Groups) 而不是具体的角色来定义共享目标。因为调整一个小组的成员比修改多条共享规则要简单得多。

总结与最佳实践

共享规则是 Salesforce 数据安全模型中一个强大而灵活的工具，它使得在保护数据隐私和促进团队协作之间取得平衡成为可能。作为 Salesforce 架构师，我们的目标是构建一个清晰、可扩展且易于维护的共享模型。

以下是我的核心最佳实践建议：

以限制性 OWD 为起点：始终遵循最小权限原则，将 OWD 设置为业务允许的最严格级别（通常是 Private），然后通过角色层次和共享规则逐层开放。
优先使用声明式工具：在标准共享规则能满足需求的情况下，不要轻易选择 Apex Managed Sharing。声明式工具更易于维护和理解。
善用公共小组：将用户组织到功能性或区域性的公共小组中，然后在共享规则中使用这些小组。这大大简化了未来的用户权限变更管理。
偏爱基于条件的规则：Criteria-based 规则比 owner-based 规则更具动态性。它根据数据本身的属性来决定共享，能更好地适应业务流程的变化。
定期审查与优化：使用 Salesforce Optimizer 等工具定期检查共享模型的健康状况。识别并重构那些不再需要或过于复杂的规则。
文档化你的共享策略：清晰地记录下为什么创建某条规则，它解决了什么业务问题。这对于新加入的管理员或开发者来说是无价之宝。

总之，一个精心设计的共享规则架构不仅能满足当前复杂的业务需求，更能为企业未来的发展和扩展奠定坚实、安全的基础。

Salesforce中文网