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

After completing this lesson, you will be able to:

After completing this lesson, you will be able to:

  • Manage Security with SAP SuccessFactors Role-Based Permissions (RBP)
  • Create Permission Groups
  • Describe SAP SuccessFactors permission roles
  • Verify the roles that grant a permission with User Role Search


SAP Successfactors offers different levels of administration to manage the amount of control each user has in the system. There are three basic levels of system administration:

  • Super Administrator

    The Super Administrator is created in Provisioning. This administrator grants permission to others to become a Super Administrator, Security Administrator, or a regular administrator.

  • Security Administrator

    The Security Administrator is responsible for managing all security through roles and permission groups in the Role-Based Permission framework.

  • Administrator

    An administrator is a user who has access to the Admin Center page in SAP SuccessFactors.

When the Super Administrator logs in for the first time, only one link on the Administrator Permissions page is visible. This is Manage Role-Based Permission Access. Choose the link to assign an employee the permission to function as a Security Administrator.

Role-Based Permissions (RBP)

Role-Based Permissions (RBP) allows the company to have as many roles in SAP SuccessFactors as the company needs and provides the ability to grant each role a different level of permission granularity.

With many traditional systems, all members of the same group, such as Human Resources (HR) managers, have the same permissions and access in the system. With the RBP framework in SAP SuccessFactors, permissions are granted based on the work that each individual or group does. RBP also determines the groups of people that specific individuals or groups can access. For example, you can create a role that is solely responsible for Compensation and Benefits and grant it to regional managers in the United States and Europe. You can apply further restrictions to a role, for example, to allow management only of full-time employees in the region assigned to a specific role. With the RBP framework in SAP SuccessFactors both granted permissions and their scope is restricted and controlled.

In a large company that needs higher levels of administrative efficiency, you can specify automatic granting rules. For example, you can grant a role, such as Regional HR Talent Manager, to all employees in the HR department within the United States. This automates permission management so that as more employee data is added to the system, permissions automatically adjust to both the rules that match the HR department in the US and for the employees in the US.

Role-Based Security Concepts

  • 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).
  • 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.
  • Administrators can define many roles.

Granting Role-Based Permissions

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.

Manage Role-Based Permission Access

Manage Role-Based Permission Access

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.

RBP Notification Settings

Increased access granularity for RBP Administrators

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.

Permission Groups

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.

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.

Dynamic Group creation

Dynamic Group creation

To create a dynamic group, go to Admin CenterManage 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.

What fields are available?

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:

Standard Fields allowed as filters in Permission Groups

























External Source Channel (Only available if Learning is enabled.)















Team View






How do you specify more fields to use?

You can specify which fields appear for defining permission groups by editing the <permission-group-filter> sub-element of the <dg-filters> element in the Succession Data Model. The <dg-filters> tag means Dynamic Groups Filters. An example XML snippet appears below, followed by a description of these XML tags.

If you do not specify any fields in the <dg-filters> XML configuration, then RBP will default to display all possible fields listed in the table above.

If a customer does not intend to use all available fields, remove the ones you are sure are not needed.

Code snippet

    <standard-element-ref refid="custom01"/> 
    <standard-element-ref refid="custom03"/> 
    <standard-element-ref refid="custom02"/> 
    <standard-element-ref refid="custom04"/> 
Copy code

The XML tags above work as follows:

The <dg-filters> tag has two sub-tags, <my-filter> and <permission-group-filter>:


Used to specify the fields that can appear in the RBP Permission Groups UI. You specify fields here by adding <standard-element-ref> or <hris-element-ref> sub elements (if Employee Central is enabled).


Used to specify the fields used in the My Groups feature, which is a separate, unrelated feature.

Permission Group modification

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

ID column in Manage Permission Groups

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.

Permission Groups Merge

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.

Modify a Dynamic 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.

Static Permission Groups

Static permission groups store a static list of users instead of a list based on dynamic criteria. Changing user information does not refresh group members. You can use static groups as RBP access groups or target groups.

Currently you can do the following with static permission groups:

  • View, Add, and Delete members of static permission groups.

  • Import static permission groups via CSV file. This can be either a full or replacement import.

Static permission group must be created by file import in Admin Center-> Manage Permission Groups->Import Static Groups

Members can be added or deleted by editing the group through UI.

Permission Roles

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.

Permission Role creation

This section describes SAP SuccessFactors permission roles and how to use them:

  • Create permission roles

  • Modify, copy, and delete permission roles

  • View user permissions

In SAP SuccessFactors, permission roles control access rights that allow an employee, or group of employees, to perform certain functions. They also control who can view the data belonging to other employees.

Some topics to consider before granting permission roles are as follows:

  • The different roles in the company

  • The employees who are assigned to each role

  • Whose data the employees can access

After all concerns are addressed, permission role creation is fairly easy. It is important to limit the number of permission groups and roles that are created. If too many roles are created, there is a risk of overlapping permissions and inconsistent access within groups. This makes modifying and deleting permission as needs change more difficult, because each overlapping role requires research to verify that they are all changed, or deleted to meet the new requirements.

Grant Permission Roles

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.

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:

t = Target needs to be defined

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.

Granting roles to groups

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.


    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.

Next Steps:

If required, assign a target population to your role.

Assigning Target Populations to a 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.


    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.

Using Relationships to Grant Permission Roles

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.

Permission Roles modification

The following items can be modified after a permission role is created:

  • Role name

  • Role description

  • Permissions assigned to a role

  • The group of people to whom a role has been assigned

  • The target populations accessible to the granted user group, if applicable

The latest Role-Based Permissions now allows you to activate and deactivate role assignments of a permission role in bulk. Previously, you could only update the status of assignments one at a time. This will help you to manage the status of role assignments more easily. 

  1. To access this feature, navigate toAdmin CenterManage Permission Roles
  2. Select the Switch to the Latest Role-Based Permissions link.
  3. Select a Role and the Permissionsand Assignments tabs will display. 
  4. Select the Role Assignments you want to activate or deactivate.
  5. Choose Activate or Deactivate to complete the process. 

Permission Roles copying

If the company has complex roles and a new similar role is required, a considerable amount of time is saved by copying and modifying an existing role, instead of creating a new one from scratch. To do this, copy the role definition, and then add or remove permissions as the role requires.

Since it is possible for an employee to be part of multiple permission groups simultaneously, caution should be used when copying roles. If permissions are overlooked, or adding or removing a permission is forgotten, the new role will not behave as expected.

Permission Roles deletion

As the company grows, some permissions roles are no longer required. To ensure that an antiquated role is not accidentally used, it is sometimes best to delete the role. Carefully review the permissions considered for deletion and ask the following questions:

  • Is anyone still using this role?

  • Can the role be modified instead of deleted?

If there are users still using the role, or if it is better to modify the role, do not delete it.

Permission Settings

The Company Info Accessand User Search Role sections contain the Company Info Access permission and User Search Target Populationpermission. The Company Info Access permission controls access to the Company Info page. The User Search Target Population permission provides a target population for any user searches that do not have a separate permission control. It also controls access to the one box people search feature.

The following search-related features are not shown if the user does not have User Search permission:

  • The global people search feature in the top navigation user interface (UI)

  • SettingsProxy

  • SettingsGroups

Compare Permission Roles

You can use User Role Search to quickly search for and compare permission roles assigned to specified users in Role-Based Permissions.

  1. Go to Admin Center.

  2. In the Manage Employees portlet, select Set User Permissions.

  3. In the Set User Permissions section, select UserRole Search.

  4. In the Selection session of the tool, enter the Access Users whose roles you are comparing.

  5. Choose the Search Roles button. The search result will display which roles, if any, grant the specified permission to either user. In the following example, you can see that both of the selected access users have permission to view address data.

  6. If a user does not have the specified permission, it is indicated as ‘no result.’

  7. You can also specify one target user, in order to see whether either of the two access users has the specified permission for the specified target.

Change history of Permission Roles

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.

Configuration requirements

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.

General best practices for RBP

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:

Governance Process

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.

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.


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.


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 CenterE-mail Notification TemplateSettings.For additional Information on E-mail Notifications, please see: Configuring E-Mail Notifications | SAP Help Portal  

The View User Permissions function

You can easily check your work by viewing the permissions for a specific user in SAP SuccessFactors. You can do this through Admin CenterSet User Permissions and using the View User Permission function.

In the View User Permission page, search for a user or a user group with Advanced Search.

To view the permissions of a user, select View Permission.

View Permission

As a System Administrator, log in to your SAP SuccessFactors instance.On the Home page, click Admin Center.Click Set User Permissions.Click Manage Permission Roles.On the View User Permission page, search for a user with Advanced Search.Beside the name of the user, click View Permission.

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

Grant Permissions to view and manage Provisioning Access and to manage RBP Access

Business example

Your customer wants to start with Role Based Permissions (RBP) and needs access to the tools so they can manage Role-Based Permission access.

Task 1: Grant Permissions to view and manage Provisioning Access

Enter Manage Provisioning Access into Action Search and notice, that there are no search results. This is because the permission is not granted yet.


  1. Use the Action Search to navigate to Manage Permission Roles and select the Full System Administrator role.

    1. Select the Permission button.

    2. In the Administrator Permissions section select the Manage System Properties link.

  2. Give your administrator following permissions: View Provisioning Access, Control Provisioning Access.

    1. Select View Provisioning Access. This gives the ability to view users with Provisioning access.

    2. Select Control Provisioning Access. This gives the ability to control which users have Provisioning access.

    3. Select Done.

    4. Select Save Changes.

  3. Test your new access.

    1. Log out of your instance and log back in to use your new RBP permissions.

    2. In Action Search type Manage Provisioning Access to access this tool.

    3. Search for the administrator2023 you created to verify it is in this list.

Task 2: Grant Permission to manage Role-Based Permission access

Your company has enabled RBP for their instance of SAP SuccessFactors. Access to manage RBP must be granted to the company administrators.

You must search for the user admin and grant them access to manage RBP.


  1. Find the administrator2023 user.

    1. Log into the instance.

    2. Use the Action Search to navigate to Manage Role-Based Permission Access.

    3. On the Manage Role-Based Permission Access screen, verify that you see the user administrator2023 that you created from Provisioning. Otherwise, choose Add User.

  2. Grant RBP to administrator2023.

    1. Make sure that the check-box Allow Access to This Page is enabled for the admin2.

    2. Make sure that the check-boxes for Role-Based Permission Admin (view)and Role-Based Permission Admin (Edit)are enabled for the administrator2023.


You have successfully searched for your admin user and granted them access to manage Role Based Permissions.

Create a Permission Role

Task 1:


  1. From the main navigation menu, verify thatMy Employee File is not an option.

  2. With the Action Search, go to Manage Permission Roles, choose Create New.

  3. Fill in the following for Name and Description:

    Role NameEmployee Data and Profile Access
    DescriptionThese permissions allow access to employee data and the views of this data on People Profile
  4. Choose Permission

  5. In Employee Data category check the box to ‘View’ the fields:

    • E-mail
    • First Name
    • Job Code
    • Last Name
    • Location
    • Username
  6. Go to the category Employee Views and select Profile.

  7. Go to the category General User Permission and select Live Profile AccessOrganization Chart Navigation Permission, Company Info Accessand User Search.

  8. Choose Done.

  9. Scroll down to the bottom of the page and in the section Grant this role to click on Add.

  10. Grant role toEveryone (All Employees).

  11. Choose the option Everyone for the target population.

  12. Click Done and Save Changes.

  13. In the warning message, click Yes.

  14. Log out and go back to the instance.

  15. From the main navigation menu go to My Employee File.

  16. Verify that you can see the seven fields you selected, if you selected more than 7 fields, you might need to choose Show More to see the last one.

Save progress to your learning plan by logging in or creating an account

Login or Register