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

To access the features "Manage Permission Groups", "Manage Permission Roles", "User Role Search", and "View User Permissions", users must be added to the group of users allowed to access the feature Manage Role-Based Permission Access available from the Action Search.

When selecting Add User and granting the permission, the new user will be in the list, with Role-Based Permission Admin box checked.

If you select the check box for Allow Access to This Page, then the users will be able to add or remove other users from the group with access to the feature. As a security precaution, the recommendation is to have at least two users with access to this page.

The RBP admin is not able to uncheck their own access to the page (since it will forbid them to view this page, thus not able to grant the access back). The checkbox needs to be always checked and not able to change (marked in gray).

A new feature added in the 1H 2022 release is RBP Notification Settings. For permission role changes that impact a large number of access users, you can now enable double-confirmation popups and e-mail notifications for RBP administrators. You can also set a threshold for triggering these notifications. For example, you can set the threshold to 80%, and notifications will be triggered if 80% or more employees are impacted by a permission role change.

Previously, RBP administrators had both view and edit access of Role-Based Permissions management by default. Now, you can grant view only access to RBP administrators.

You can manage RBP administrator access under Admin Center Manage Role-Based Permission Access. Existing RBP administrators have both the Role-Based Permission Admin (View) and the Role-Based Permission Admin (Edit) access by default. You can review and update their access accordingly.

Some RBP administrators only need view access but not edit access. We now provide more granularity to RBP admin access management to meet your needs.

• 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 HXM 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.

Note

SAP SuccessFactors allows administrators to manage RBP security setting changes, such as assigning users to roles and creating permission groups, through an Application Program Interface (API).

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

To create a dynamic group, go to Admin Center → 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 multiple 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 now 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.

• 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.

Note

If you want to grant a role to a named user, you first have to create a group and add the user to this group. Then you can grant the role to the just created group.

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.

1. Use the Action Search to navigate to Manage Permission Roles.

2. Select one of the permission roles you created.

3. In the ‘Grant this role to’ section of the Permission Detail screen, chooseAdd.

4. When the Grant this role to screen displays, select Permission Group.

   

5. Choose Select to select the access groups you wish to assign to this permission role.

   You can allow managers to have the same permissions and define how many levels up in the hierarchy you want this permission to be granted. However, allowing respective managers to have the same permissions may have a negative impact on the performance. The hierarchy then has to be checked whenever such a manager tries to access an element which was permissioned this way.

6. Exclude Granted Users: For some permissions, it might be necessary to exclude the granted users from applying the permissions on themselves. For this, select Exclude Granted User from having the permission access to themselves.

   Example:

   If the role grants permission to edit the salary, you want to prevent the members of this permission group to be able to edit their own salary as well.

7. Choose Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.

8. Choose Save Changes to complete creating the role.

If required, assign a target population to your role.

1. Use the action search to navigate to Manage Permission Roles.

2. Select one of the permission roles you created.

3. In the Grant this role to.... section of the Permission Detail screen, click Add.

4. Select Everyone or chooseTarget population of to select a group.

   

5. Choose Select to select the target groups that you want to assign to this permission role.

6. Exclude Granted Users:

   For some permissions, it might be necessary to exclude the granted users from applying the permissions on themselves. For this, select Exclude Granted User from having the permission access to themselves.

   Example:

   If the role grants permission to edit the salary, you want to prevent the members of this permission group to be able to edit their own salary as well.

7. Choose Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.

8. Choose Save Changes to complete creating the 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 now view the change history of a permission role using the latest 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.

You can now 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:

Start with most generic roles	We recommend starting with the most generic role such as an "All Employees Role" and casting the net as wide as possible to include all of the permissions that should be given to everyone. For example, in this role include all of the publicly-viewable fields in the Employee Profile.
Avoid redundancy	For additional roles, work on an exception basis and include only the unique extra permissions that the role should have beyond other roles. This practice will help reduce the number of roles in the system, which will both be easier to maintain, and will help improve system performance. Note It is important to keep in mind that the stronger permissions always wins.
No overlap between roles	A user should not get the same permission from different roles. If users have multiple roles and get the same permissions from different roles, this slows down the system response time for these users.
Limit the number of groups and roles	In general, keep the number of groups and roles as low as possible. This will both reduce the maintenance effort and ease the troubleshooting in case of any issues. Remember, that you can grant a role to multiple groups, so you do not have to duplicate roles just to assign them to different groups. From a performance point of view, we recommend a maximum of 1000 dynamic permission groups. Dynamic groups are based on rules in contrast to static groups which contain named users. These static groups do not count against the 1000 recommendation. Note that this is not a hard limit, it is a guidance recommendation. The system will allow you to exceed 1000 dynamic groups, but the consequences of exceeding 1000 dynamic groups will be to reduce system performance.
Naming Conventions	Agree on a naming convention for groups and roles. This makes the maintenance much easier, especially for large implementations. For groups, you could, for example, use the prefixes "Granted:" and "Target:"
Meaningful Group Names, Role Names, and Role Descriptions	Meaningful group and role names and role descriptions help customers to identify the correct groups and roles later during maintenance and troubleshooting. The role descriptions should state clearly the purpose of the role and not just repeat the role name. Additionally, advise the customers that they maintain a change login the role description field. It should include the change, the date, and who made and approved the change. The "View change history" function also delivers this information; however, looking up the description field is much quicker.
Governance	It's key that customers define a governance on RBP as soon as possible within the project. They should define how changes to RBP will be handled in the future: Who should be able to make changes? How can a change be requested? Who needs to review it and needs to be involved in deciding whether to make the change or not? These questions are especially important in large organizations where the departments tend to be separated from each other. If one department requests a change, this might also have an impact on other departments, so all parties need to agree on it. Some customers may also want to introduce the concept of separation of duties for the administration of RBP. How to achieve this is described in the Special Requirement: Separation of Duties in RBP Administration chapter.
Run the RBP Check Tool	The RBP check tool section in this guide provides information on how to run RBP checks and maintain good system performance. This tool provides a report that highlights all potential risks for the specific RBP configuration settings.

Note

E-mail Notifications: As a Role-Based Permission (RBP) administrator, you can now enable e-mail notification for changes to large-size permission groups. A new Role-Based Permission Notification – Group Change e-mail template is now available under Admin Center → E-mail Notification Template → Settings.For additional Information on E-mail Notifications, please see: Configuring E-Mail Notifications | SAP Help Portal  

You can change the permissions for an individual, and then verify the change from the View Permissions page.