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

Objectives

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

Administrators

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.

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.

Note

With the release update 2405 the Legacy Role-Based Permissions where replaced with the Latest Role-Based Permissions. Legacy Role-Based Permissions will reach End of Development on November 15th, 2024. It will reach End of Maintenance and be deleted on May 16th, 2025. The latest Role-Based Permissions is now the default permission role configuration tool.

Role-Based Security Concepts

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

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 HCM suite.

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.

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.

Dynamic Group creation

Dynamic Group creation

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.

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

benchStrength

citizenship

city

country

custom01

custom02

custom03

custom04

custom05

custom06

custom07

custom08

custom09

custom10

custom11

custom12

custom13

custom14

custom15

dateOfBirth

dateOfPosition

department

division

ethnicity

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

futureLeader

gender

hireDate

impactOfLoss

jobCode

keyPosition

location

married

minority

nationality

newToPosition

reasonForLeaving

riskOfLoss

state

Team View

timeZone

title

username

zipCode

jobLevel

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 CenterManage Permission GroupsImport 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.

Unique Identifiers for Permission Roles and Role Assignments

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

Maximum Number of Role Assignments to Bulk Activate or Deactivate

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.

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.

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:

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.

Procedure:

  1. Use the Action Search to navigate to Manage Permission Roles.
  2. Select Add Role Assignments one of the Permission Roles you created.
  3. Choose a name.
  4. Select Next.
  5. Select From groups.
  6. Select Select groups to choose the access groups you wish to assign to this permission role.
  7. Choose Select.
  8. 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.
  9. Select Next
  10. 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.
  11. Select Next twice.
  12. Select Save.

Next Steps:

If required, assign a target population to your role.

Assigning Target Populations to a Role

Procedure:

  1. Use the action search to navigate to Manage Permission Roles
  2. Select Add Role Assignmentsone of the Permission Roles you created.
  3. Choose a name.
  4. Select Next twice.
  5. Select Everyone or Filtered by to select a group.

    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.

  6. Choose Next to Define Target Criteria to all or to Restrict Target Criteria.
  7. Choose Next.
  8. Choose Save.

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.  Click on Assignments
  5. Select the Role Assignments you want to activate or deactivate.
  6. Choose Activate or Deactivate to complete the process. 

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?

Note
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

Search, Sort, and Filter Role Assignments

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

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 User Role Search.

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

  3. Choose the Search Roles button. The search result will display which roles, if any, grant the specified permission to either user.

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

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

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

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 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 in the Action Search by the searching 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.

Working with Role Based Permissions

Business Example

Security Administrators must know how to create and manage permission groups and permission roles.

Steps

  1. Create a Permission Group for the Human Resources Department

    1. Use Action Search navigate to Manage Permission Groups.

    2. Click Create New.

    3. Enter a new Group Name: Granted Human Resources.

    4. In Choose Group Members, under People Pool, select the category Department.

    5. In the keyword search field, click on the magnifying glass to see the list of departments.

    6. Select Human Resources.

    7. Click Done to save the selected department for that group.

    8. Under Active Group Membership click the Update button.

    9. Click the number to see the members in this group.

    10. Click close.

    11. Click Done to save your group.

  2. Create a Permission Role and assign the Permission Role to a Permission Group Part 1 of 2

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

    2. Click Create.

    3. Under 1. Name and description in the Role Name field enter Human Resources. In the Description field enter Assignments for Human Resources Role for THR80.

    4. Click Next.

    5. Under 2 Add Permissions search in User Permissions and click General User Permission. Check the box Select All to select all permissions in the General User Permission category.

    6. Click Save.

  3. Create a Permission Role and assign the Permission Role to a Permission Group Part 2 of 2

    1. In the checkbox Success click on Yes.

    2. Under 1 Basic Information enter in the Name field:Role Assignment for Human Resources for THR80.

    3. Click on Next.

    4. Under 2 Grant Access To select From Groups and click on Select Groups.

    5. Select Human Resources. After selecting it, confirm it appears under Selected Items.

    6. Click Select.

    7. Click Next.

    8. Under 3: Define a Target Population select Everyone.

    9. Click Next.

    10. Click Save.

Result

You have successfully created a permission group, a permission role, and mapped the group to the role. 

Log in to track your progress & complete quizzes