精通 Salesforce 共享规则：实现最优数据安全的深度解析
大家好，我是您今天的 Salesforce 架构师。在 Salesforce 庞大而精密的世界中，数据安全和访问控制是整个平台的基石。一个设计良好的安全模型不仅能保护敏感信息，还能提升用户协作效率。今天，我们将深入探讨 Salesforce 数据可见性模型中的一个关键组件——Sharing Rules (共享规则)。作为架构师，我不仅会告诉您它是什么，更会从性能、可扩展性和治理的角度，剖析其背后的原理和最佳实践。
背景与应用场景
在构建 Salesforce 安全模型时，我们遵循“从最严格到最宽松”的原则。这个模型的基础是 Organization-Wide Defaults (OWD, 组织范围默认设置)。OWD 定义了对任何对象记录的默认访问级别。例如，如果我们将 Account 对象的 OWD 设置为 "Private"，那么默认情况下，用户只能看到和编辑他们自己拥有的客户记录，其他人的记录对他们完全不可见。
然而，在现实业务中，严格的隔离往往无法满足协作需求。这时，我们就需要一种机制，在 OWD 的基础上，有选择性地、横向地扩展数据访问权限。这正是 Sharing Rules 发挥作用的地方。它允许我们基于特定条件，将记录的访问权限授予那些在 Role Hierarchy (角色层级) 中无法直接访问这些记录的用户。
常见的应用场景：
- 区域协作：一家公司的销售团队按区域划分（东部、西部）。OWD 设置为 Private。为了促进跨区域的大客户合作，需要让东部大客户团队的负责人能够看到西部大客户团队拥有的、年收入超过100万美元的客户记录。
- 跨部门支持：客户支持团队需要处理由销售团队创建的“高优先级”客户的 Case。虽然 Case 的 OWD 是 Private，但我们需要创建一个共享规则，将所有与高优先级客户关联的 Case 记录，自动共享给“高级技术支持”公共小组。
- 合作伙伴赋能：在 Partner Community 中，我们需要让合作伙伴用户（Partner User）能够看到由内部销售团队拥有的、与他们共同跟进的商机（Opportunity）。一个基于条件的共享规则可以实现这一点，例如，当商机的“合作伙伴”字段等于该合作伙伴的公司名时，就将该商机共享给他们。
- Guest User 访问：对于一个公开的 Knowledge 知识库或产品目录网站（Experience Cloud Site），我们需要让未经身份验证的访客用户（Guest User）能够看到特定的产品记录或文章。Guest User Sharing Rule 是唯一能实现此目的的机制。
从架构师的角度看，Sharing Rules 是解决“横向访问”问题的标准、声明式工具，它在不破坏角色层级垂直结构的前提下，提供了灵活的数据可见性扩展能力。
原理说明
Sharing Rules 的核心原理非常简单：它们从不限制访问，只授予额外的访问权限。 这意味着共享规则永远不会覆盖比 OWD 更严格的权限。如果 OWD 是 "Public Read/Write"，那么再创建共享规则就没有意义了，因为所有人都已经拥有了最高访问权限。
当一个共享规则被创建或修改时，Salesforce 会在后台运行一个计算过程，在每个符合条件的记录上创建一个名为 [ObjectName]Share 的共享对象记录（例如 AccountShare, OpportunityShare）。这个 Share 对象记录明确定义了哪个用户或组（User or Group ID）对哪条记录（Record ID）拥有什么样的访问级别（Access Level）。正是这些 Share 记录，构成了 Salesforce 底层的数据共享机制。
Salesforce 提供两种主要类型的共享规则：
1. Owner-based Sharing Rules (基于所有者的共享规则)
这种规则基于记录的所有者。它将由特定 Public Groups (公共小组)、Roles (角色)、Roles and Subordinates (角色和下属) 或 Territories (区域) 成员所拥有的记录，共享给其他 Public Groups、Roles 或 Roles and Subordinates。
- 示例：将所有由“西部销售代表”角色拥有的客户记录，以“只读”权限共享给“市场营销”公共小组。
2. Criteria-based Sharing Rules (基于条件的共享规则)
这种规则基于记录本身的字段值，而不是所有者。当记录的字段满足预设的条件时，它就会被共享给指定的用户组。
- 示例：将所有“客户”对象上“行业”字段为“金融服务”的记录，以“读/写”权限共享给“金融客户专家”角色及其下属。
无论是哪种类型，您都需要定义三个关键要素：
- 要共享哪些记录？ (通过所有者或字段条件定义)
- 要与谁共享？ (目标 Public Group, Role, Role & Subordinates)
- 授予什么级别的访问权限？ (Read-Only 或 Read/Write)
理解 Share 表的存在对于架构师至关重要，因为它直接关系到系统的性能和扩展性。大规模的数据加载、所有者变更或共享规则的修改，都可能触发大规模的 Share 表重新计算（Recalculation），这在拥有数千万条记录的对象上可能会成为性能瓶颈。
示例代码
虽然共享规则通常通过 Salesforce 的 Setup 界面进行配置，但在 DevOps 和元数据驱动的开发实践中，我们通常使用 Metadata API 来管理和部署它们。这确保了环境间的一致性，并能将共享设置纳入版本控制。以下是来自 Salesforce 官方文档的 Metadata API 示例，展示了如何在 Account.sharingRules 文件中定义共享规则。
这是一个典型的元数据文件，您可以将其包含在 package.xml 中，通过 Ant Migration Tool 或 Salesforce CLI 进行部署。
<?xml version="1.0" encoding="UTF-8"?>
<SharingRules xmlns="http://soap.sforce.com/2006/04/metadata">
<!-- 示例 1: 基于条件的共享规则 (Criteria-based Sharing Rule) -->
<sharingCriteriaRules>
<!-- 共享规则的唯一名称 (API Name) -->
<fullName>Share_High_Value_Accounts_with_Key_Account_Managers</fullName>
<!-- 显示在UI上的标签 -->
<label>Share High Value Accounts</label>
<!-- 要共享给的目标群体，这里是一个名为 Key_Account_Managers 的公共小组 -->
<sharedTo>
<group>Key_Account_Managers</group>
</sharedTo>
<!-- 定义筛选记录的条件 -->
<criteriaItems>
<!-- 条件1: AnnualRevenue 字段大于 1000000 -->
<field>AnnualRevenue</field>
<operation>greaterThan</operation>
<value>1000000</value>
</criteriaItems>
<criteriaItems>
<!-- 条件2: Active__c 字段等于 'Yes' -->
<field>Active__c</field>
<operation>equals</operation>
<value>Yes</value>
</criteriaItems>
<!-- 授予的访问级别：Read (只读) -->
<accessLevel>Read</accessLevel>
<!-- 描述信息 -->
<description>Shares accounts with annual revenue over $1M with the Key Account Managers group.</description>
</sharingCriteriaRules>
<!-- 示例 2: 基于所有者的共享规则 (Owner-based Sharing Rule) -->
<sharingOwnerRules>
<!-- 共享规则的唯一名称 (API Name) -->
<fullName>Share_West_Coast_Leads_with_Marketing</fullName>
<!-- 显示在UI上的标签 -->
<label>Share West Coast Leads with Marketing</label>
<!-- 定义记录所有者的来源，这里是名为 West_Coast_Sales 的角色及其下属 -->
<sharedFrom>
<roleAndSubordinates>West_Coast_Sales</roleAndSubordinates>
</sharedFrom>
<!-- 要共享给的目标群体，这里是 MarketingTeam 角色 -->
<sharedTo>
<role>MarketingTeam</role>
</sharedTo>
<!-- 授予的访问级别：Read (只读) -->
<accessLevel>Read</accessLevel>
<!-- 描述信息 -->
<description>Shares all leads owned by the West Coast Sales team with the Marketing team.</description>
</sharingOwnerRules>
</SharingRules>
通过代码管理共享规则，可以极大地提高部署的可靠性和可重复性，是企业级 Salesforce 项目管理的关键一环。
注意事项
在设计和实施共享规则时，作为架构师，我强烈建议您考虑以下几点：
权限优先级
共享规则只扩展记录的访问权限，它不能超越用户的对象级权限。例如，如果一个用户的 Profile (简档) 或 Permission Set (权限集) 中没有对 Opportunity 对象的“读取”权限，那么即使您通过共享规则将一条商机记录共享给他，他依然无法看到该记录。对象权限永远是基础。
性能影响与扩展性
这是最关键的架构考量。每个对象最多可以有 300 个共享规则，其中最多 50 个可以是基于条件的（这个限制可能随版本更新，请以官方文档为准）。过度使用基于条件的共享规则，特别是在数据量巨大的对象上，可能会导致性能问题。当记录被创建、更新（特别是所有者或条件字段被更改）时，Salesforce 需要重新评估共享规则，这会消耗系统资源。在设计时，应优先考虑 owner-based 规则，因为它通常比 criteria-based 规则性能更高。
共享重新计算 (Sharing Recalculation)
当您修改共享规则、角色层级或组成员时，Salesforce 会启动一个后台任务来重新计算共享。在大型组织中，这个过程可能需要几分钟甚至几小时。在此期间，用户看到的访问权限可能是旧的。进行此类变更前，应规划好时间（例如在非工作时间），并通知受影响的用户。
数据倾斜 (Data Skew)
当一个用户拥有海量记录时（例如，超过10,000条），对该用户所有权的变更或角色层级的变更会导致所谓的“所有权倾斜(Ownership Skew)”，从而引发长时间的共享重新计算。同样，当一个父记录下有大量子记录时（例如一个客户下有几万个联系人），也会产生数据倾斜，影响性能。在设计数据模型和所有权策略时，必须避免这种情况。
考虑替代方案
对于那些极其复杂、动态或需要实时计算的共享逻辑，标准的共享规则可能无法满足。在这种情况下，应考虑使用 Apex Managed Sharing (编程方式共享)。通过 Apex 代码，您可以直接操作 Share 表，实现任何自定义的共享逻辑。但请注意，这是最后的手段，因为它会增加代码的复杂性和维护成本。
总结与最佳实践
Sharing Rules 是 Salesforce 数据安全模型中不可或缺的工具，它为基于 OWD 和角色层级的垂直共享模型提供了强大的横向扩展能力。作为架构师，我建议遵循以下最佳实践，以构建一个既安全又高效的共享模型：
- 坚持最小权限原则：将 OWD 设置为最严格的级别（通常是 Private），然后按需逐步开放访问权限。
- 优先利用垂直共享：在创建共享规则之前，优先考虑是否能通过优化角色层级来满足需求。角色层级共享的性能通常是最好的。
- 善用公共小组：在共享规则中，优先将记录共享给 Public Group，而不是具体的 Role。这样，当需要调整访问权限的人员时，您只需修改 Public Group 的成员，而无需修改共享规则本身，从而避免了不必要的共享重新计算。
- 简化条件：设计 criteria-based 规则时，尽量保持条件简单。复杂的公式或跨对象字段会增加计算开销。
- 定期审计：定期审查您的共享规则，删除那些因业务流程变更而不再需要的规则。这有助于保持共享模型的整洁和高效。
- 在沙箱中充分测试：在生产环境中部署任何新的共享规则之前，务必在具有代表性数据量的 Full Sandbox 中进行充分测试，以评估其对性能的潜在影响。
- 文档化：为每个共享规则编写清晰的描述（Description），解释其业务目的。这将极大地帮助未来的管理员或架构师理解您的设计意图。
通过深思熟虑地规划和应用共享规则，您可以构建一个强大、可扩展且易于维护的 Salesforce 安全架构，为您的业务保驾护航。
评论
发表评论