2.1 Role-Based Permissions: Groups, Roles, and Target Populations

2.1 Role-Based Permissions: Groups, Roles, and Target Populations

Quick Answer: Role-Based Permissions (RBP) is a three-step model. Create groups (who), create a permission role (what), and grant the role to groups for a target population (to or for whom). Dynamic groups update automatically as employee data changes. Static groups hold a fixed list of users. After any RBP change, affected users must log out and log back in before the new permissions apply.

Why RBP Matters for C_THR81

SAP tags C_THR81 with the skill Access Controls, and almost every Employee Central configuration ends with a permission step. A newly enabled HRIS field, an MDF object, a Quick Action template, or the Position object stays invisible until RBP grants access. RBP is the suite-wide authorization model, so the same concepts apply in Employee Central, Position Management, and the talent modules.

The Three Building Blocks

1. Permission groups define who is granted access. They can also define a target population.
2. Permission roles bundle permissions that grant access to data and functions.
3. Role assignments grant a role to one or more groups (or to everyone) and define the target population where required.

SAP summarizes this as: who (the permission group) can do what (the permission role) to, or for whom (the target population). For example, managers (granted users) can view dashboards (the role) for their team (the target).

Dynamic Permission Groups

In Manage Permission Groups > Create New, you name the group, choose members from people pools, and optionally exclude people. How you combine criteria changes the result:

• Adding a category inside a people pool narrows the group, like a Boolean AND. Country = United States and Department = Sales gives fewer members.
• Adding another people pool widens it, like a Boolean OR. US employees or Sales employees gives more members.
• You can include up to four people pools in one group.
• Exclusions remove a population from the group, for example everyone in a specific division.
• Update under Active Group Membership shows the current member count. Selecting the number lists the members.
• After saving, you can lock a group so its membership stops changing. Most groups stay unlocked so they stay dynamic.

Group criteria can use standard fields such as department, division, location, jobCode, country, custom01–custom15, hireDate, and username. They can also use HRIS fields when Employee Central is enabled. In EC, additional HRIS fields are made available to the People Pool through Dynamic Group Filters in Manage Business Configuration (Section 7.2). Each group has a system-generated ID column to tell groups apart, and groups can be edited, copied, deleted, summarized, or have their change history viewed.

Static Permission Groups

A static group stores a fixed list of named users. Changes to user data do not refresh its membership. Static groups:

• must be created by file import in Manage Permission Groups > Import Static Groups (full or replacement import)
• can have members added or deleted afterward in the UI
• can be used as access groups or target groups

Permission Roles

In Manage Permission Roles > Create, you give the role a name and a meaningful description, then select permissions. Permissions are split into User Permissions (for example General User Permission, Employee Data, Employee Central Effective Dated Entities, Miscellaneous Permissions) and Administrator Permissions (for example Manage System Properties, Metadata Framework, Manage Position).

• A permission marked with a "t" icon needs a target population. Permissions that only open an application, such as Learning access, need no target.
• Selecting Edit on a field implies View, so the View checkbox becomes read-only.
• Copying a role copies only its permissions. You must reassign groups, target populations, and relationships manually.
• Before deleting a role, check whether anyone still uses it and whether modifying it would be better.
• You can activate or deactivate up to 30 role assignments at a time on the role's Assignments tab.
• An assignment can use Effective Duration with a start date and an end date.

Granting Roles and Defining Targets

When a role is granted to everyone or to a dynamic group, the target population can be:

• Everyone
• the granted user's Department, Division, Location, Manager, Peers, or the Granted User (Self)
• a selected permission group

The option Exclude granted users from having the permission access to themselves is common for sensitive data. For example, HR managers may see the potential ratings of everyone in their location except their own.

Relationship-Based Grants

Roles can also be granted through relationships:

• Hierarchical: employee–manager, second manager, and alternate manager relationships along a reporting line.
• Non-hierarchical: HR manager, matrix manager, and custom manager. An employee has only one manager, one second manager, and one HR manager, but can have several matrix and custom managers.

Employee self-service uses the target the granted users themselves. Manager self-service typically grants the manager role for direct reports.

Search and Company Information Permissions

Two general permissions affect many screens. Company Info Access controls the Company Info page. The User Search target population controls user searches that have no separate permission, and the one-box people search. Without User Search, the global people search, Settings > Proxy, and Settings > Groups are hidden.

Testing Changes

Always log out and log back in after changing permissions, then test by proxying as a representative user (Section 2.3). THR81's exercises follow exactly this pattern: create the group, verify membership, create the role, grant it, exclude self where needed, save, log out, and then proxy to confirm.