3602976 - Explanation of Role Assignment when grant access by "Manager in the following goups" and Target Population is "Granted Users' Direct Reports"

In Manage Permission Roles, when Role Assignment is assigned with Manager relationship and "Grant the same access to their managers (1 level up or more level up)" is checked, the Higher-level managers only have permission for manager's Direct Report but do not have permission for the manager.

Direct Report User Hierarchy:

• User A reports to User B.
• User B reports to User C.
• User C reports to User D.

Steps:

1. Create a Permission Group:
   • Name: Role Assignment Test_Permission Group
   • Members: Add User C to this group.
2. Configure Permission Role Assignments:
   • Navigate to the Manage Permission Role page.
   • Edit the desired permission role. Create an assignment with the following settings:
     • Access Population:
       • "Managers in the following groups: Role Assignment Test_Permission Group"
       • "Grant the same access to their managers (1 level up or more)"
       • "Granted Users’ Direct Reports"
       • "Grant the same access to their direct reports (1 level down or more)"
3. Resulting Permissions:
   • User D will have permissions for User A and User B.
   • User D will not have permissions for User C, despite User C being User D's direct report. 

In this case, User D will have permissions for User A and User B, but not user C. This is because the Target Population includes the Direct Reports whose manager belongs to this permission group, but not the direct reports of the Higher-Level managers (User D in this case). 

Permissions for Direct Managers:

• If you want to assign the same permission to level up direct managers for their direct reports, you can add them to the relevant permission groups.

Permissions for Second Managers:

• The same logic applies to the Second Manager with the Direct Manager.
• Granting a Second Manager access with 1+ levels up or more and targeting their Second Report 1+ levels down or more allows their own Second Manager to access their Second Report's Second Report.

Example:

• User A → User B (Second Manager) → User C (Second Manager) → User D (Second Manager)
  • Granting User C access with 1+ levels up and targeting 1+ levels down, User D gains permission to access User A and User B, but not User C.

Simplified:

• Granting User C (Second Manager) permissions upwards, their manager (User D) can access User C's reports (User A & B), but not User C themselves.

By following this logic, you can effectively assign permissions up the management chain for Second Managers.

Permissions for HR Managers:

• Granting an HR Manager access with 1+ levels up and targeting their HR Report 1+ levels down allows their Direct Manager to access their HR Report's Direct Report.
• This logic also applies to Matrix Managers in relation to HR Managers.

Example:

• Direct Report: User A → User B (Direct Manager)
• HR Report: User B → User C (HR Manager) → User D (HR Manager)
• User C's Direct Manager: User E
  • Granting User C access with 1+ levels up and targeting 1+ levels down, User D (HR Manager) gains no additional permissions, but User E (Direct Manager) gains permission to access User A and User B.

Simplified:

• Granting User C (HR Manager) permissions upwards, their Direct Manager (User E) can access User C's HR reports (User A & B), but not higher-level HR managers (User D).

By following this logic, you can effectively assign permissions for HR Managers and their corresponding Direct Managers.

Managers in the following groups,Grant the same access to their managers (* level up),Granted Users’ Direct Reports,Grant the same access to their direct reports (* level down) , KBA , LOD-SF-PLT-RBP , Role Based Permissions , LOD-SF-PLT , Platform Foundational Capabilities , How To