Managing security using SAP SuccessFactors Role-Based Permissions (RBP)

• Administrators can define many roles.
• Groups can be dynamic which allows us to automate the assignment of permissions. For example, a group of granted users can be "All employees in the Sales department".  As employees are transferred into and out of the sales department, their permissions will automatically adjust.
• The role defines access to data and functionality. This is where you define what you want your role to do in SAP SuccessFactors. For example, should the role be allowed to view dashboards?
• Once the role is defined, you grant the role to groups of users represented by the Granted Users circle.
• Lastly, you restrict the granted users to perform the role on target users.  For example, you may decide that managers (Granted Users circle) can view dashboards (defined in the role) on their team Target Users circle).

It is a simple process to grant RBP in SAP SuccessFactors:

1. Create Groups: Create a group and grant it the required permission, then create groups to be managed by users with those permissions.

2. Create a Permission Role: Define the different roles. Permission roles define access to data and application functionality.

3. Grant the Role to a User or Group: Add the target group created in step one with the roles created in step two. This is also referred to as linking the role to a target population.

Think of this process as who (the permission group) can do what (permission role) to, or for whom (the target population).

The SAP SuccessFactors Role-Based Permissions implementation guide available on SAP Help Portal holds the comprehensive list of RBPs used across the SAP Successfactors HCM suite.

In the SAP SuccessFactors RBP framework, permission groups are used to define groups of employees who have the same group of permissions. For example, you can create a permission group called US Compensation Managers to include all US-based managers who have access to compensation information. Similarly, you can create permission groups that define the target population accessible to a granted user group, or user. For example, a US Employee group that the US Compensation Managers group oversees.

Permission groups also allow you to group employees who match a pre-defined condition. You can create this condition from a single parameter such as HR for an HR department. Or you can have multiple conditions. For example, you can create a US HR group with the conditions of department and location, to create a group that includes only HR employees in the US. You can add further parameters to refine the group. For example, to limit the US HR group to include only US HR employees who have access to the financial department, this creates US HR Finance.

Watch the 'Create Permission Groups' video for an in-depth explanation.

To create a dynamic group, go to Manage Permission Groups and choose Create New. In the Group Name field, enter a name for the dynamic group. Choose group members by selecting from the People Pool dropdown menu. You can include up to four People Pools in the same group if required. Then choose people to exclude from the group. When finished, choose Done.

The fields that can be used when defining permission groups are any of the standard fields listed below, as well as HRIS fields when Employee Central is enabled. The standard fields available are limited to the list below.

Standard Fields allowed as filters in Permission Groups:

You can modify the parameters of a permission group at any time. The following list includes some additional modifications:

• Permission group name

• The conditions that determine the members of the permission group

• Inclusion of members to the permission group

• Exclusion of members from the permission group

Role-Based Permission (RBP) administrators see a new column, ID, on the Manage Permission Groups admin page.

The IDs are system-generated serial numbers according to the creation time of the permission groups.

You have unique identifiers to differentiate permission groups.

When the company goes through organizational changes that alter the access requirements for certain systems, or groups in SAP SuccessFactors, it becomes necessary to modify permission groups. For example, if the company merges two departments, US Finance and Canada Finance, into a new North America Finance department, an administrator can modify the permission group US Finance to North America Finance by including Canadian Finance employees in the US Finance group.

To modify a dynamic group, select an action from the Take Action dropdown menu of the group to be modified. Edit the group by selecting, and/or excluding new group members. It is also possible to copy, delete, view summary, or view change history for the group. When you are finished making changes, choose Done.

RBP uses permission roles to group a set of permissions. After grouping the permissions into a role, you can assign the role to a group of users, granting them access to certain tasks and features in your system.

Permission roles consist of a set of permissions that give employees access rights to an employee or a group of employees. As such, an employee or a group that has been granted a permission role has access to certain aspects of the SuccessFactors application or to aspects of employee data. With this access, they can perform functions within the application for other groups of employees.

Role-Based permissions allow you to grant a role to a specific employee, a manager, a group, or to all employees in the company. The roles can provide very granular permissions, as this example illustrates:

Example: There may be roles such as ‘HR Compensation and Benefits Manager’, ‘HR Manager for Sales’, and ‘HR Learning and Development Manager’. While all three are HR managers, their roles have been distinctly carved out — one handling compensation and benefits, another handling the sales team, and the third handling Learning and Development.

When your permissions roles consist of one or more permissions that require a target population, you'll need to specify a target to complete creation of the role. Roles that require a target population will contain a permission that gives a group access to perform actions or view information for other employees.

Example: A Manager may have a role where one permission allows the manager to modify the salary for all of their direct reports. In this example, the manager's direct reports represent the target population needed for the permission role.

Customers can have as many permission roles as the company requires.

Just like for the Permission Groups you can differentiate permission roles and role assignments by their IDs. The IDs are system-generated serial numbers according to the creation time of the permission roles and role assignments. They’re more accurate than names in differentiating permission roles and role assignments

As a Role-Based Permissions administrator, you can activate and deactivate multiple role assignments on the Assignments tab of a permission role. You can activate or deactivate up to 30 role assignments at a time.

You can assign a permission role to everyone or to a subset of employees, determined by permission groups, target populations, or by relationships. When defining a role in RBP, you can assign the role to a group that you've created, or you can assign roles based on hierarchical relationships. Please note that the assignment can also have an effective duration.

Permission groups: You assign a permission role to a defined group of users. However, relationships can also play a role here as you can define that the granted user's managers have the same permissions. You can also define how many levels up in the hierarchy you want this permission to be granted.

Target Population: Depending on the permissions included in the role, you might also have to define the target population. Not all permissions require you to define a target population. For example, if the permission includes just the access to an application (such as the Learning Access Permission), there is no need to add a target group. For certain permissions, in the Permission settings screen, a target population must be defined. This is identified by the "t" icon next to the permission name with the following text displayed:

Relationships: Access groups can be defined using relationships (for example, manager-employee relationship). These relationships can be hierarchical or non-hierarchical.

When a permission role is assigned to everyone or to a dynamic group, you will have the following options for the target population:

• Everyone
• Target Population of:

  - Granted User's Department,

  - Granted User's Division,

  - Granted User's Location,

  - Granted User's Manager,

  - Granted User's Peers and

  - Granted User (Self)

• You can select a permission group

There is also an option to "Exclude granted users from having the permission access to themselves". This is an interesting option for some organization when we speak of the potential for example. A group of HR Managers should be able to see the potential information of everyone in their location but not their own potential rating.

After creating your roles, you must assign the role to a group of employees. This ensures that employees are given access the permissions they need to perform their tasks.

If required, assign a target population to your role.

There are relationships that can be specified through employee fields, and managed through tools, like the employee data.

General Relationship Types:Hierarchical relationships are characterized by a reporting line between the granted user and the target user. These are relationships between employees and their managers, and employees and their second managers or alternate managers. Non-hierarchical relationships on the other hand are single-level relationships. These include the relationship of an employee to the HR manager, the matrix manager and custom manager. While each employee can have only one Manager, one Second Manager and one HR Manager, they can have multiple Matrix Managers and Custom Managers.

A permission role can have many role assignments. A Role-Based Permissions administrator can use the search, sort, or filter functions to narrow down role assignment search in the latest Role-Based Permissions.

For further information check: Searching, Sorting, and Filtering Role Assignments

As an RBP administrator, you can view the change history of a permission role using the Role-Based Permissions. You can also compare two versions of a permission role to check which permissions are added or removed.

You can view the change history of a permission role under Admin Center Manage Permission Roles [select a permission role] View History. Or, you can go into the role details page and choose the View History button. Here you can use two Buttons: Show All and Show Difference. The Show Difference button offers a simplified page of permission role changes where you can quickly view all the differences without scanning through a long list of permission details

You can have version control on permission roles.

A permission role change record is created when you add or remove permissions or role assignments of a permission role. But only permission changes are highlighted when you compare two versions. So, after you add a role assignment to a permission role, and compare the current version with the previous record, no change is highlighted.

When planning the RBP setup for the customer, it's crucial that you keep the impact on system performance and the maintenance effort in mind. In addition, it is crucial to agree on a governance process for further changes. We recommend the following: