精通 Salesforce 角色层级：全面的数据可见性指南

十月 28, 2025

背景与应用场景

大家好，我是一名 Salesforce 管理员。在我的日常工作中，最核心的任务之一就是确保“正确的人在正确的时间看到正确的数据”。这不仅关乎数据安全和合规性，更直接影响到业务流程的顺畅和效率。在 Salesforce 强大的安全模型中，Role Hierarchy (角色层级) 是实现这一目标的基础支柱，它是一种直观且强大的工具，用于控制记录级别的垂直数据访问权限。

想象一个典型的销售型企业，其组织架构通常是这样的：一线销售人员 (Sales Reps) 向销售经理 (Sales Managers) 汇报，销售经理又向区域总监 (Regional Directors) 汇报，最终汇报给销售副总裁 (VP of Sales)。在这个结构中，业务需求通常是：

销售人员只能看到自己拥有的客户和商机记录。
销售经理需要能够查看和管理其团队所有成员的客户和商机，以便进行指导和业绩评估。
区域总监需要查看其管辖区域内所有销售团队的数据，以制定区域战略。
销售副总裁则需要拥有整个销售部门所有数据的全局视野，以便做出最高级别的决策。

如果 Salesforce 中没有一个自动化的机制来处理这种自上而下的数据可见性，我们可能需要手动为每位经理共享下属的每一条记录，这无疑是一场灾难。Role Hierarchy 正是为了解决这类基于组织汇报关系的垂直数据共享而设计的。它将公司的组织结构图映射到 Salesforce 中，自动地将下属拥有的记录访问权限授予其上级。

原理说明

要深入理解 Role Hierarchy，我们必须先了解它在 Salesforce 整个记录级共享模型中的位置。该模型像一个层层叠加的过滤器，每一层都可能为用户开放更多的访问权限。

1. 组织范围默认设置 (Organization-Wide Defaults, OWD)

这是整个共享模型的基石。OWD 定义了所有用户对非其拥有的记录的默认访问级别。对于一个对象，OWD 可以设置为 Private (私有)、Public Read Only (公共只读) 或 Public Read/Write (公共读/写)。如果某个对象的 OWD 设置为 Private，那么默认情况下，用户只能看到自己拥有的记录，其他任何人都看不到。

2. 角色层级 (Role Hierarchy)

Role Hierarchy 正是在 OWD 的基础上发挥作用的。它的核心原则非常简单：位于层级中较高级别的用户，自动继承其所有下属角色的用户所拥有和共享的记录的访问权限。

例如，如果 Opportunity (商机) 对象的 OWD 是 Private，销售代表 A 只能看到自己创建的商机。但如果销售经理 B 是 A 在角色层级中的上级，那么 B 就能自动看到 A 的所有商机，并且通常拥有与 A 相同的访问级别（读取、编辑、删除等），甚至更高。这种权限的传递是沿着角色层级树向上进行的，直至最高层。

一个关键的设置是每个对象共享设置中的 Grant Access Using Hierarchies (使用层级授予访问权限) 复选框。对于所有标准对象，此选项默认启用且无法更改。但对于自定义对象，管理员可以选择禁用它。如果禁用，那么该自定义对象的记录将不会通过角色层级进行垂直共享，即使 OWD 设置为 Private。这在某些不希望上级自动看到下级数据的特殊业务场景中非常有用。

3. 共享规则 (Sharing Rules) 与手动共享 (Manual Sharing)

当我们需要进行横向（例如，销售团队 A 与支持团队 B 共享数据）或更复杂的条件性共享时，Role Hierarchy 就无能为力了。这时，我们会使用 Sharing Rules (共享规则) 和 Manual Sharing (手动共享) 来进一步开放访问权限。它们与角色层级共同构成了 Salesforce 灵活的共享体系。

总结来说，Role Hierarchy 专注于解决“自上而下”的垂直共享问题，是模拟企业管理结构、实现数据自动向上汇总的关键工具。它与 OWD 紧密配合，为数据可见性设定了清晰的基线和继承规则。

示例代码

作为管理员，我们主要通过点击式界面 (Declarative) 来配置角色层级。但在某些高级场景下，例如构建复杂的报表、自定义组件或进行数据分析时，我们需要通过代码（如 Apex 或 SOQL）来查询和利用角色层级信息。以下是一个常见的 Apex 代码示例，用于获取指定角色的所有下属角色 ID。这在需要查询某个经理及其整个团队（包括下属经理的团队）的所有记录时非常有用。

此代码的逻辑基于 Salesforce 官方对象 UserRole 的结构。每个 `UserRole` 记录都有一个 `ParentRoleId` 字段，指向其在层级中的直接上级。我们可以通过递归查询来构建完整的下属角色树。

// Apex Class to find all subordinate role IDs for a given role
public class RoleHierarchyService {

    // This map will store the hierarchy: RoleId -> List of direct child RoleIds
    private static Map<Id, List<Id>> roleHierarchyMap;

    /**
     * @description Public method to get all subordinate role IDs for a given starting role ID.
     * @param roleId The ID of the role to start from.
     * @return A Set of all subordinate role IDs.
     */
    public static Set<Id> getAllSubordinateRoleIds(Id roleId) {
        // Initialize the map if it's the first run
        if (roleHierarchyMap == null) {
            buildRoleHierarchyMap();
        }

        Set<Id> subordinateRoleIds = new Set<Id>();
        // Start the recursive search
        findSubordinates(roleId, subordinateRoleIds);
        return subordinateRoleIds;
    }

    /**
     * @description Private helper method to build a map of the entire role hierarchy.
     *              This is an optimization to avoid querying the database repeatedly in the recursion.
     */
    private static void buildRoleHierarchyMap() {
        roleHierarchyMap = new Map<Id, List<Id>>();
        // Query all roles that have a parent. Based on UserRole object from official documentation.
        for (UserRole r : [SELECT Id, ParentRoleId FROM UserRole WHERE ParentRoleId != NULL]) {
            if (!roleHierarchyMap.containsKey(r.ParentRoleId)) {
                roleHierarchyMap.put(r.ParentRoleId, new List<Id>());
            }
            roleHierarchyMap.get(r.ParentRoleId).add(r.Id);
        }
    }

    /**
     * @description Private recursive method to traverse the hierarchy and collect subordinate IDs.
     * @param currentRoleId The role ID to find subordinates for in the current iteration.
     * @param collectedIds A Set to accumulate the results.
     */
    private static void findSubordinates(Id currentRoleId, Set<Id> collectedIds) {
        // Check if the current role has any children
        if (roleHierarchyMap.containsKey(currentRoleId)) {
            // Get all direct children
            List<Id> childRoleIds = roleHierarchyMap.get(currentRoleId);
            for (Id childId : childRoleIds) {
                // Add the child to the collected set
                collectedIds.add(childId);
                // Recursively call the same method for the child to find their children
                findSubordinates(childId, collectedIds);
            }
        }
    }
}

// How to use this service to query Opportunities for a manager and their entire team:
// 1. Get the manager's Role ID
// User manager = [SELECT Id, UserRoleId FROM User WHERE Username = 'manager@example.com' LIMIT 1];
// Id managerRoleId = manager.UserRoleId;

// 2. Get all subordinate role IDs
// Set<Id> allRoleIds = RoleHierarchyService.getAllSubordinateRoleIds(managerRoleId);

// 3. Add the manager's own role to the set to include their own records
// allRoleIds.add(managerRoleId);

// 4. Query for Opportunities owned by users in these roles
// List<Opportunity> teamOpportunities = [SELECT Id, Name, Owner.Name FROM Opportunity 
//                                         WHERE Owner.UserRoleId IN :allRoleIds];
// System.debug('Found ' + teamOpportunities.size() + ' opportunities for the team.');

注意事项

在设计和维护 Role Hierarchy 时，作为管理员，我们必须牢记以下几点，以避免潜在的性能问题和管理混乱：

1. 性能影响

角色层级是 Salesforce 共享计算的核心。一个过于复杂、庞大或不平衡的层级会严重影响性能。特别是当您创建或更新用户、更改角色、或进行大量数据插入/更新时，系统需要重新计算共享规则 (Sharing Recalculation)。

层级深度：避免创建过深的层级（例如，超过10层）。
层级宽度：避免在某个角色下直接挂载过多的下属角色（例如，超过1000个）。
所有权偏斜 (Ownership Skew)：避免将大量记录（例如，超过10,000条）的所有权分配给一个位于层级底部的用户，因为其上级的所有访问权限计算都会变得非常复杂。

2. Grant Access Using Hierarchies 设置

请记住，对于自定义对象，您可以禁用基于层级的访问授予。在创建新对象或评估现有对象时，务必思考：“上级用户是否真的需要自动访问其下属创建的所有这类记录？” 如果答案是否定的，请果断禁用此选项，这不仅符合业务需求，还能提升性能。

3. 与 OWD 的关系

Role Hierarchy 永远是用来“开放”权限的，而不是“限制”权限的。如果一个对象的 OWD 是 Public Read Only，那么所有用户已经拥有了对所有记录的只读权限，角色层级在“读”这个权限上就失去了意义（尽管它仍然可以传递“编辑”等更高级别的权限）。请始终将 OWD 作为数据访问权限的起点。

4. 门户和社区用户角色

社区和门户用户的角色处理方式比较特殊。通常，他们的角色会自动置于其所属客户 (Account) 的所有者 (Owner) 的角色之下。但这并不意味着客户所有者可以自动看到其所有门户用户的记录。这是一种特殊的结构，旨在将外部用户与内部层级隔离开，需要特别注意。

总结与最佳实践

Role Hierarchy 是 Salesforce 数据安全模型中不可或缺的一环，它优雅地解决了企业中普遍存在的垂直数据可见性需求。作为管理员，我们的目标是构建一个既能满足业务需求，又高效、可维护的角色层级。

最佳实践：

忠于组织结构： 角色层级应尽可能地反映您公司真实的汇报关系图。不要为了解决一些特殊的共享需求而扭曲角色层级，对于那些横向或例外的场景，请使用共享规则 (Sharing Rules) 或其他工具。
保持扁平与简洁： 努力让层级结构尽可能扁平化。一个简洁的层级不仅易于理解和管理，还能带来更好的系统性能。
一个用户，一个角色： Salesforce 的设计是一个用户只能分配一个角色。在规划时要明确这一点。
定期审查和维护： 企业组织结构是会变化的。应定期（例如每季度或每半年）审查角色层级，确保它仍然与公司的最新结构保持一致，并清理不再使用的角色。
与配置文件 (Profiles) 区分： 新手管理员常混淆角色和配置文件。请牢记：Profiles (和 Permission Sets) 决定用户“能做什么”（对象和字段权限），而 Roles 决定用户“能看到哪些记录”（记录级访问）。两者相辅相成，共同构成了用户的完整权限。

通过遵循这些原则，您可以构建一个稳固、高效的角色层级，为您的 Salesforce 组织打下坚实的数据安全基础，确保业务在清晰的权限边界内顺畅运行。

Salesforce中文网