SF RBP Impl PDF

IMPLEMENTATION GUIDE | CONFIDENTIAL
SAP SuccessFactors Foundation

Document Version: Q4 2018 – 2018-11-16
Implementing Role-Based Permissions

© 2018 SAP SE or an SAP affiliate company. All rights reserved.
THE BEST RUN

Content
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2 What are Role-Based Permissions?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.1 Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Creating Static Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Creating Dynamic Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
View, Edit, Copy, and Delete Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.2 Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Creating Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Assigning Permissions to a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
View, Edit, Copy, and Delete Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Creating a New Role for External Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 Permission Role Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Assigning Permission Groups to a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Assigning Target Populations to a Role. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Using Relationships to Assign Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .26
3 Implementation Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4 Initial Setup Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Creating a Super Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.2 Enabling RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Refreshing RBP after Changes in Provisioning Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.4 Granting Permissions to Manage RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .34
4.5 Granting Yourself and Project Team Members All Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
5 Designing the RBP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.1 Checking Available Permissions in a New Customer Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.2 Review Permissions in Existing Customer Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .37
5.3 Which modules are covered by RBP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.4 Recommendations and Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Special Requirement: Separation of Duties in RBP Administration. . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.5 Basic Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
5.6 Copying Roles and Groups between Test and Production Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . .48
6 Preparing the Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1 Ensuring that Test Instance and Production Instance are In Sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .50
6.2 Configuring Fields for Setting up Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

2 CONFIDENTIAL Content
What Fields Are Available?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
How do you specify which fields to use?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
7 Conducting Tests. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
8 RBP Ad Hoc Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54
9 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.1 How can you check the permissions assigned to a user?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
9.2 How can you run an ad hoc report?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
9.3 Cross Domain Ad Hoc Reporting Between the RBP and Employee Central Domains. . . . . . . . . . . . . . . . .61
9.4 How do you run a user search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
10 Copying RBP Configuration to Production Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
11 Using the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

11.1 Benefits of the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.2 Check Results. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
11.3 Creating Support Tickets from the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
12 RBP Configuration Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

12.1 Does the Everyone Group Exist?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.2 Do Roles Exist Without Groups or Users?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
12.3 Do Roles Exist Without Target Population?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .76
12.4 Do Group Names Exceed 1000 Characters?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
What are Rules in RBP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
12.5 Do Target Group Names Exceed 1000 Characters?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
12.6 Does a User Have the Same Permission More Than 30 Times? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
12.7 Does a Role Have More Than 100 Rules?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
What are Rules in RBP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
13 Running the RBP Diagnosis Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Content CONFIDENTIAL 3
What's New in Implementing Role-Based
Permissions Guide
The most recent changes made to this guide are listed below.
Q4 2018
The following table summarizes changes to this guide for the Q4 2018 release.
What's New Description More Info
No Change
Q3 2018
Information about the Check Tool and

updated RBP general topics have been
added.
Q2 2018
There were no updates to this document

in Q2 2018.

4 CONFIDENTIAL What's New in Implementing Role-Based Permissions Guide
Q1 2018

in Q1 2018.
Q4 2017

in Q4 2017.
Q3 2017
Added the field: External Source Chan This standard field type was added to the The External Source Channel is only
table in the What Fields Are Available? available if Learning is enabled.
nel.
section.
Added a new Dynamic Group User Type: See the Dynamic Permission Groups
External Learning User. topic for more information.
Added information about External User This brief topic describes one exception See the External User Management topic
Management. in relation to target populations and ex for more information.
ternal Learning users.
Added information about External User This topic describes how to set the Target See the Granting Permission Roles topic
Target Population. Population when granting permission for more information.
roles for external Learning users.

What's New in Implementing Role-Based Permissions Guide CONFIDENTIAL 5
Q2 2017

in Q2 2017.
Q1 2017
New Cross Domain Ad Hoc Report func Administrators can run reports between Cross Domain Ad Hoc Reporting Be
tionality. the Role-Based Permission (RBP) do tween the RBP and Employee Central Do
main and Employee Central (EC) domain. mains [page 61]
Q4 2016
New Diagnosis Tool You can use this tool to run RBP checks Running the RBP Diagnosis Tool [page
and generate a report (in one click) that
81]
highlights all potential risks for the spe
cific RBP configuration settings in the
customer instance.
Q3 2016
New button to add users to the Static Added the procedure to use the new Add
Permission Group User button for the Static Permission
Group.
New button to delete users from the Added the procedure to use the new
Static Permission Group Delete button for the Static Permission
Group.

6 CONFIDENTIAL What's New in Implementing Role-Based Permissions Guide
Add an External Users (External Learn Added the procedure to create a role Creating a New Role for External Users
ers) Role mapping for external users. [page 20]

What's New in Implementing Role-Based Permissions Guide CONFIDENTIAL 7
1 Introduction
This content is intended for Professional Services consultants to enable them to implement Role-Based
Permissions (RBP) for customers. It describes the steps and provides recommendations and best practices.
It is important to note that RBP is the only permission model that is available to new customers. New customers
cannot disable RBP to use legacy permissions. Existing customers, new companies of Professional Edition or free
trial are not affected.
The first section familiarizes you with the concept of role-based permissions. The Implementation Sequence in the
second section guides you through the complete process. We strongly recommend following the implementation
sequence to accomplish a smooth implementation.
The subsequent sections detail the individual tasks that make up the process. Finally, you will find troubleshooting
information in case problems occur with the permissions.
 Note
This implementation content covers all general aspects of setting up RBP. The implementation handbooks for
the individual modules may contain additional module-specific information.

8 CONFIDENTIAL Introduction
2 What are Role-Based Permissions?
Role-Based Permissions (RBP) is a security model that allows you to restrict and grant access to your SAP
SuccessFactors HCM Suite. RBP controls access to the applications that employees can see and edit. This is a
suite-wide authorization model that applies to the majority of the SAP SuccessFactors products.
Open this video in a new window
The RBP security authorization model uses groups and roles to organize employees (groups) and permissions
(roles) to control access to your system; By organizing employees into groups and permissions into roles you can
assign a group of employees the same set of permissions by assigning them a role.
 Note
RBP is approved for organizations with up to 300,000 employees. We will continue to raise this bar in the
future. When in doubt, contact customer support.
Role-based permissions contain three main elements: Permission Groups, Permission Roles, and Target
Populations. Permission groups are a set of employees who share certain attributes such as City or Job Code and
require access to a similar set of tasks within your system. Roles are defined as a set of permissions. You can assign
the permission roles, you define, to a permission group and if the role requires that you define a target population,
meaning a group to perform tasks for, you'll assign the target population when you define the role.
Target populations are groups that are assigned to permission roles when the permission granted is performed on
behalf of other employees.
 Tip
We recommend that you create groups before creating roles so that during role creation, you can select the
group for which to grant the role. In addition, you’ll need defined groups for roles that require a target
population.
Permission Groups [page 10]

Permission groups are used to define groups of employees who share specific attributes. You can use
various attributes to select the group members, for example a user's department, country, or job code.
Permission Roles [page 16]

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 Role Assignments [page 21]

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. Some roles will
require that you also assign target populations, they're only necessary for certain permissions in a role and
your system will notify you when a target population is required.

What are Role-Based Permissions? CONFIDENTIAL 9
2.1 Permission Groups
Permission groups are used to define groups of employees who share specific attributes. You can use various
attributes to select the group members, for example a user's department, country, or job code.
 Example
There might be a permission group called "Human Resources in US", which lists all US-based employees who
work in the HR department. To define this group, you would specify that users must match the selection criteria
"Country = United States" and "Department = HR".
 Note
The attributes or selection criteria that are available for defining groups are configurable.
In RBP, you can assign permission roles to permission groups. In addition, you use groups to define the target
population a granted user has access to.
 Example
The group "Human Resources in US" might have access to the group "US Employees".
Groups configured with criteria other than specific user names are called dynamic (as opposed to static),
which means that the assignment of employees into and out of a group is automated. 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. This automation will save you time and money.
This is especially beneficial for large organizations that need higher levels of administrative efficiency.
Creating Static Permission Groups [page 10]

Static permission groups are created and modified by adding individual user names to a group using an
excel spreadsheet. They store a static list of users instead of a list based on dynamically generated criteria.
Changing user information does not modify group members, you must redefine group members by
importing an updated spreadsheet.
Creating Dynamic Permission Groups [page 14]

Dynamic permission groups are generated automatically when the attributes of employees match the
group selection criteria. Administrators can create and manage dynamic permission groups for both
employees and external users.
View, Edit, Copy, and Delete Permission Groups [page 16]

You can edit, copy, and delete static or dynamic permission groups. For dynamic groups, you can also view
the group's change history.
2.1.1 Creating Static Permission Groups
Static permission groups are created and modified by adding individual user names to a group using an excel
spreadsheet. They store a static list of users instead of a list based on dynamically generated criteria. Changing

10 CONFIDENTIAL What are Role-Based Permissions?
user information does not modify group members, you must redefine group members by importing an updated
spreadsheet.
Procedure
1. In the Admin Center, search for Manage Permission Groups.

2. Click Import Static Groups to create or modify a group.
3. Select between Full Replace or Delta Replace.
A full replace, creates or entirely replaces a group, while a delta replace adds members to an already existing
group.
4. Download a blank CSV template after you've chosen an import type. The Full Replace template has two column
headers, GROUPNAME and USERID. The Delta Replace has an additional Action column.
5. For each user that you add to a group, add the group name to the GROUPNAME column and user's ID to the
USERID column.
 Note
For new users, you can create user IDs in the upload file.
 Note
Character encoding of your file should be Unicode(UTF-8). The maximum file size is 20MB. If your import
file exceeds 20MB, you can either split the file into several smaller files or request Professional Services to
modify the system configuration file.

6. Select the file with your data by clicking Choose File.
7. Click Validate File to validate file format, file size, etc.
8. If the validation is successful, click Upload to import the static permission groups.
If your file has errors, they display at the top of the Import Static Group window.
 Note
For one group type, a maximum of two jobs can run at the same time.
Results
After the upload completes, the system sends you a notification with success or error messages. Successfully
created groups display in the group list after refreshing your system.

2.1.1.1 Adding Individual Members to Static Groups
You can add members to a static group in your system or by importing an excel file to your system.
Procedure

2. Click the name of the static group you're updating.
The Permission Group screen displays.

3. To add a user to a static group, click Add User.
4. Search for the users you'd like to add to the group.
Entering keywords in the search field displays user names.

5. Select each user you want to add to the group.
Each user you select automatically displays in the right pane.

6. Click Done.
The users you selected are added to the group immediately.

2.1.1.2 Deleting Members from Static Groups
Although you add members to a static group using a spreadsheet, you can delete static group members using the
system.
Procedure

2. Click the name of the static group you're updating.
The Permission Group screen displays.

3. Select the users that you want to delete from the group.
4. Click Delete.
The list of users updates immediately.

5. Click Close.
Results
Deleted members will no longer have access to the tasks or data of the group.
2.1.2 Creating Dynamic Permission Groups
Dynamic permission groups are generated automatically when the attributes of employees match the group
selection criteria. Administrators can create and manage dynamic permission groups for both employees and
external users.
Procedure

2. Click Create New to create a new permission group.
The Permission Group page opens.

3. Enter a name for your permission group in the Group Name field.
4. Choose a User Type for your group.
The available user types vary depending on how your system is configured. Possible values may include:
○ Employee (default)
○ External Learning User

 Note
The External Learning User option is only available if you have Learning enabled in your system.
When defining a dynamic group for an external learning user, you can identify an External Source Channel to
complete the criteria for inclusion. This allows external learning users to be defined based on the source of
origin. The external source channel is only available to SAP SuccessFactors Learning customers. The External
Learning User must be enabled in Provisioning for external learner and external source channel to be available.
 Tip
When defining External Learning User groups in your system, it is recommended that you do not create
more than 50 groups.
5. Choose the group selection criteria from the People Pool, in the Choose Group Members section.
Depending on the complexity of your permission group selection criteria, you can choose multiple people
pools.
6. In the Search Results screen, enter a search term or click the  search, to display all available values.
For some categories, a smaller pop-up window appears where you can enter additional values or information,
such as Time Zone settings. If you select the Team View category, you can use hierarchical relationships to
specify the group. This allows you to apply rules such as: everybody in Carla Grant's team, all levels deep.
7. Make your selection and click Done.
8. If you want to add another condition for defining the people pool, click Add another category and choose a
category and item. If you use two or more categories, this functions as an AND operation, that is, only users are
selected who meet all selection criteria.
 Example
If you want to create a group of sales employees working in the US, you would need to choose the category
Department and select Sales. You add a second category Country and select USA.
9. Complex group definitions may require you to use multiple people pools. If you use two or more people pools,
these people pools functions as an OR operation, that is, all users are selected who fulfill the selection criteria
of at least one pool.
Click Add another People Pool and then add categories and items.
 Example
You have two different offices: An office in Chicago and an office in Boston. Each office has a Sales team and
a Finance team. You only want to include Sales employees from the Chicago office and Finance employees
from the Boston office. You'll need to create two separate pools then.
 Note
The number of people pools in a group is limited to three.
10. If there are employees you'd like to exclude from the Permission Group definition, select them in the Exclude
these people from the group section.
11. If you want to prevent the group being updated automatically when new employees match the selection
criteria, click Lock group.

12. Click Done to complete the process.
2.1.3 View, Edit, Copy, and Delete Permission Groups

You can edit, copy, and delete static or dynamic permission groups. For dynamic groups, you can also view the
group's change history.
Context
 Note
You can only delete a permission group if it has no associated role.
Procedure
1. Go to the Admin Center Tools and search for Manage Permission Groups.
2. In the Manage Permission Groups screen, click the Take Action dropdown menu next to the permission group
you want to modify.
3. Choose the desired action.
2.2 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 with 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.
 Note
Customers can have as many permission roles as the company requires.
Creating Permission Roles [page 18]

Permission roles contain a group of permissions that you can grant to an employee or a group of employees
known as the Granted Users Circle. In general, it's best practice to define your user groups before defining
your permission roles.
Assigning Permissions to a Role [page 18]

After creating groups and roles, you'll need to assign permission roles to your employee groups.
View, Edit, Copy, and Delete Permission Roles [page 19]

You can edit, copy, or delete a permission role, view a summary of a permission role, and view its change
history.
Creating a New Role for External Users [page 20]

Role-based permissions support the role of External User and allows the External Learner User limited
access to complete specific tasks or training.

2.2.1 Creating Permission Roles
Permission roles contain a group of permissions that you can grant to an employee or a group of employees known
as the Granted Users Circle. In general, it's best practice to define your user groups before defining your permission
roles.
Procedure
1. Go to the Admin Center.

2. In the Tools Search, search for Manage Permission Roles.
3. To create a permission role, click the Create New.
The Permission Role Detail page opens.

4. In the Role Name, type a name describing of what the role allows you to do.
5. In the Description, provide a statement describing what the role allows an employee to do. Add a note about
when the role was created and by whom.
After this role is successfully created, the new role will be listed on the Permission Role List page.
6. Click Save Changes.
Results
You have a permission role and you can now add permission and assign it to a group.
Next Steps
After you've created a permission role, you'll need to assign permissions to the new role.
2.2.2 Assigning Permissions to a Role
After creating groups and roles, you'll need to assign permission roles to your employee groups.
Procedure
1. In the Permission Settings section, click the Permission button to specify the permission you want to assign to
the role. The Permission Settings window opens.

2. On the left side of the page, you'll see the different permission categories. Click a permission category to reveal
the different permissions.
The list of permissions associated with this category is displayed.
3. Select the checkboxes next to the permissions you'd like to grant to the role.
4. Click the Done button when you finish marking your selections.
Next Steps
Assign a target population, if your role indicates that a target is needed.
2.2.3 View, Edit, Copy, and Delete Permission Roles
You can edit, copy, or delete a permission role, view a summary of a permission role, and view its change history.
Context
When you copy a role, only the permissions get copied over. You will need to manually grant employees access to
this new role.

Procedure
1. Go to the Admin Center Tools and search for Manage Permission Groups.
2. In the Permission Role List screen, click the Take Action dropdown menu next to the permission role you want
to modify.
3. Choose the desired action.
2.2.4 Creating a New Role for External Users
Role-based permissions support the role of External User and allows the External Learner User limited access to
complete specific tasks or training.
The external user role can be granted to the Everyone (External Learner) group. Permissions for the external user
role can be set to grant access to SAP Jam and SAP SuccessFactors Login, Learning modules, and Mobile.
For complete details about External Learning, please refer to the Offering Learning to the Extended Enterprise
guide.
2.2.4.1 External User Management
If you have external users, consider creating a management system for them so that you can maintain their access.
When you have external users in your extended enterprise, your plan for maintaining them should include: resetting
user passwords, granting access, and so on. In most cases, you manage external users as you do any other users.
One exception is target populations. External users can be a unique target population. For example, if you want to
manage external users in learning, you must add All (External Learning) to the target population of users managed
by the administrator.

2.2.4.2 Mapping External Users from Learning Sites to SAP
SuccessFactors Roles
Create a role mapping for external users so that users who log in through SAP SuccessFactors Learning sites are
granted the correct permissions.
Prerequisites
Role Based Permissions (RBP) must be enabled.
Procedure
1. Log in and go to Admin Center.

2. In Tools, click See All.
3. In Search Tools, type Manage Permission Roles and then click Manage Permission Roles.
4. Click Create New Role For External User.
5. In User Type, select External Learner, and then click Done.
6. Type a name and description for the role and then click Permissions.
The Permission Settings page opens.
7. In User Permissions General User Settings , select User Login.
8. In User Permissions Learning , select Learning Access Permission.
You can select additional permissions. For example, you can grant the external users access to SAP Jam.
9. Click Done.
You return to the Permission Role Detail page.

10. Click Add.
The Grant this role to... page opens.

11. In Grant role to, select Everyone (External Learner).
12. Click Done.
You return to the Permission Role Detail page.

2.3 Permission Role Assignments
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. Some roles will require that you also assign target
populations, they're only necessary for certain permissions in a role and your system will notify you when a target
population is required.
● 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.
 Note
A target population for an external Learning user can be defined two ways:
○ Select Everyone (External Learner)
○ Select Target population of: and click Select, to select groups
● Relationships: Access groups can be defined using relationships (for example, manager-employee
relationship) that are derived from the job relationship object. These relationships can be hierarchical or non-

hierarchical. You can find more information in the following chapter Using Relationships to Grant Permissions
[page 26].
●  Note
If you allow the respective managers to have the same permissions, this 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.
2.3.1 Assigning Permission Groups to a Role

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

3. Select one of the permission roles you created.
4. In the Grant this role to section of the Permission Detail screen, click Add.
5. When the Grant this role to screen displays, select Permission Group.

6. Click 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.
7. 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.
8. Click Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.
9. Click Save Changes to complete creating the role.
Next Steps
If required, assign a target population to your role.
2.3.2 Assigning Target Populations to a Role
Target populations are assigned to roles that require tasks to be performed on behalf of another employee.
Context
Target populations allow you to give employees such as managers and administrators access to data or tasks that
need to be maintained for other employees. Depending on the permissions included in the role, you may need 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.
Procedure


4. In the Grant this role to section of the Permission Detail screen, click Add.
5. Select Everyone or choose Target population of to select a group .
6. Click Select to select the target groups that you want to assign to this permission role.
 Example

2.3.3 Using Relationships to Assign Permissions
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.
Employee Central Only: If employees have global assignments (that is, a job in another country), they have both a
home manager and a host manager. In addition, they have a home HR manager and a host HR manager. All
managers need to have access to both the home jobs of the employees as well as to the host jobs of the employees.
This is covered by the following additional relationship types for global assignments:
Employee Central Only: Relationship Types for Global As

The Five General Relationship Types signments
Manager Home Managers
Second/Alternate Manager Home HR Managers
HR Manager Host Managers
Matrix Manager Host HR Managers
Custom Manager
2.3.3.1 Assigning Permissions using Relationships
After defining permission roles, you can use relationships to establish access to those roles instead of permission
access groups.
Context
Using relationships to grant access permissions gives you the added ability to define access and target populations
using your organizations hierarchy.
Procedure

4. In the Grant this role to section of the Permission Detail screen, click the Add to select the employees to be
granted this permission.
5. When the Grant this role to screen displays, select a relationship type.
These relationships can be hierarchical or non-hierarchical.
 Note
If you allow the respective managers to have the same permissions, this 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. Assign a target population to the role:
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.
○ Target Population: A target population for an external Learning user can be defined two ways:
○ Select Everyone (External Learner)
○ Select Target population of: and check the checkbox to Select... to define the group

 Example
2.3.3.2 Specifying the Hierarchy Depth
Understand how to use hiearchy depth when assigning permissions to your users.
When granting permissions using hierarchical relationships, you can specify how many levels down to go in the
hierarchy for the target population. For example, you can indicate that Managers can see performance ratings on
their direct reports (1 level deep), or allow it to go deeper into their team, that is 2 levels down or all levels.
When granting permissions to non-hierarchical relationships (HR, Matrix and Custom Managers), you can follow
this non-hierarchical relationship for only one level. Beyond the first level, you can cross over to the standard
manager hierarchy if desired to go deeper.

For example, using the Matrix Manager relationship, you can use hierarchical depth to accomplish the following:
● 1 Level Deep: Matrix Managers can view ratings information for their Matrix Reports.
● 2 Levels Deep: Matrix Managers can view ratings information for their Matrix Reports and the Direct Reports of
their Matrix Reports.
● All Levels Deep: Matrix Managers can view ratings information for their Matrix Reports (1 level deep) and the
Direct Reports, all levels deep of the manager hierarchy of their Matrix Reports.
The following graphic illustrates the different hierarchical depths you can specify when you use the Matrix Manager
relationship:

3 Implementation Sequence
This table gives you an overview of the main steps in their sequential order. We recommend that you follow this
sequence.
What you need to do… Find more information in…
Create a "Super Administrator" either before or right after you Creating a Super Administrator [page 32]
have enabled RBP.
 Caution
After you have enabled RBP, only super administrators can
log in.
Enable RBP in provisioning How do you enable RBP? [page 33]
Determine who needs permission to manage RBP and grant Granting Permissions to Manage RBP [page 34]
the permission.
 Note
Only a super administrator can grant this permission.
Ensure you and other project team members have access to all Granting Yourself and Project Team Members All Privileges
functions by granting yourself and them all privileges. [page 35]
Design the RBP configuration: Design the RBP Configuration [page 36]
● Check what modules and functions the customer actually

uses. For customers migrating from the old permission
framework to RBP, review the existing permissions.
● Make yourself familiar with the module coverage of RBP
● Observe best practices
● Clarify the customer requirements and document the
groups, roles, and role assignments in a workbook.
Prepare the test instance Ensuring that Test Instance and Production Instance are in
● Ensure that the data on the test instance and on the pro Sync [page 50]
duction instance are in sync Configuring Fields for Setting up Permission Groups [page
● Configure the fields that need to be available for selecting 50]
group members
Create groups in the test instance.
Create roles and grant roles to groups on the test instance.
Conduct tests to check if groups and roles have been set up Conducting tests [page 53]
correctly

30 CONFIDENTIAL Implementation Sequence
What you need to do… Find more information in…
Enable RBP reporting so that it is ready to use for the cus Enable Reporting [page 54]
tomer. Reporting also helps to analyze problems that were

found during the tests.
● Import standard spreadsheet reports to the customer in

stance
● Enable and set up RBP ad hoc reports
If problems were found in the tests, analyze the RBP configura- Troubleshooting [page 59]
tion with the "View User Permissions" tool in Admin Tools and
through RBP ad -hoc reports.
After successful testing, copy the RBP configuration to the pro Copying RBP Configuration to Production Instance [page 66]
duction instance

Implementation Sequence CONFIDENTIAL 31
4 Initial Setup Tasks
4.1 Creating a Super Administrator
Creating a Super Administrator ensures that you can log on to the system after enabling role-based permissions
(RBP). Super administrators can always access the Manage Role-Based Permission Access link in Admin Tools to
begin the work of setting up security for other users, including granting permission for other users to log in.
Context
You can create a Super Administrator before or after you have enabled RBP.
If you create the Super Administrator before enabling RBP, your user becomes as a super administrator, allowing
you to log on to new RBP instances.
Procedure
1. Log on to the instance.

2. Grant all administrative privileges to your own user, then log out.
Results
You can now log on to new RBP instances.
 Note
If you've already enabled RBP, you can log on to Provisioning, then create an administrative user.
Administrators created through provisioning after RBP is already enabled are marked as Super Administrators
in the system.

32 CONFIDENTIAL Initial Setup Tasks
4.2 Enabling RBP
Procedure
1. Log on to Provisioning.
2. Under Company Settings, select Role-based Permissions.
 Note
To be able to set permissions for Employee Views, Profile V12 needs to be enabled.
4.3 Refreshing RBP after Changes in Provisioning

Configuration
Once RBP is enabled, changes to settings in provisioning (like enabling Goals module or Succession Planning
module) will not immediately appear to RBP permissions settings. You can refresh RBP in one of the following ways:
● In Provisioning, under Company Settings, click Refresh next to "Refresh RBP Permission Configuration". This
will trigger a real time refresh of the RBP permissions to become aware of the features you have enabled.
● Export and re-import the Succession Data Model. This will trigger a real time refresh of the RBP permissions to
become aware of the new features you have enabled.
● Wait 24 hours, and the system will automatically refresh.

Initial Setup Tasks CONFIDENTIAL 33
4.4 Granting Permissions to Manage RBP
The role-based permissions concept assumes that there are just a few users per company with the ability to
manage role-based permissions. Typically, you want to keep the number of people able to maintain permissions as
limited as possible as there should be no need to update them frequently.
Context
There are three types of administrators for each customer instance:
● The Super Administrator (sometimes referred to as Super User) is the only user who is allowed to log on to
the system after RBP is enabled. The Super Administrator can grant other users the right to manage role-
based permissions. As a Super Administrator, you can grant permissions to manage permissions to yourself
and any other consultants working on the project. In addition, you can grant this permission to the Security
Admin of the customer.
● A Security Admin is responsible for managing security through roles and permission groups.
● An Admin is any user with access to the Admin Tools.
To grant the permission to manage role-based permissions:
Procedure
1. Log on to the instance as Super Administrator.

2. Go to Admin Tools.
3. In the Manage Employees portlet, select Set User Permissions, then choose Manage Role-Based Permission
Access.
 Note
Only Super Admins can see the Manage Role-Based Permission Access link when they log in. Security
Admins who are not also Super Administrators cannot see this link.
4. Select Add User.

5. Search for and select the employee(s) you'd like to grant permission to.
6. Click Grant Permission.
Related Information
Creating a Super Administrator [page 32]

34 CONFIDENTIAL Initial Setup Tasks
4.5 Granting Yourself and Project Team Members All
Privileges
You can use groups to grant yourself and other project members access privileges.
Context
You and other project team members require access to all modules and data.
Procedure
1. Create a group, for example "System Admins All Modules", then assign all relevant admin users to this group.
2. Create a role, for example, "System Admin All Modules", add all available permissions to it, and grant this role
to the just created group with the target population of everyone.
Related Information
Permission Role Assignments [page 21]

Initial Setup Tasks CONFIDENTIAL 35
5 Designing the RBP Configuration
Each implementation project needs a clear definition of what permissions are needed for the individual user
groups. To define this configuration, you should take into account the customer's requirements and limitations
given the module coverage of RBP, and the best practices considering maintenance and performance aspects.
We recommend that you follow these steps:
1. For new customers, get an overview of what permissions can be granted [page 37] in the customer instance
depending on the activated modules. If you are migrating a customer instance from a non-RBP system to an
RBP enabled system, start by reviewing the permissions settings [page 37] in the non-RBP instance.
2. Go through the RBP module coverage [page 37] section and evaluate the impact for your RBP
implementation.
3. Familiarize yourself with the recommendations and best practices [page 46].
4. See the basic roles [page 47] section to learn about the common roles that are usually created for customers.
5. Conduct requirements sessions with the customer to clarify their needs. Ask them to determine the
appropriate roles, what permissions those roles require, and who would be granted those roles.
6. Create a workbook that lists the groups, roles, and what permissions they contain, and the mapping of roles to
groups. For defining these, it is useful to have a good understanding of how you can grant roles to groups [page
21], especially how you can use relationships [page 26].
Typically, the workbook functions as a statement of work for your project. That is, it does not contain the
complete RBP setup, but only the limited number of groups and roles you will set up. The remainder should
then be configured by the customers themselves to familiarize them with RBP as much as possible. This way
you can ensure they’re autonomous and ready to manage RBP after you leave the project.
As a guideline, we suggest that you set up a maximum of 10 roles. If you have access to Product Central, you
can download a sample workbook: http://confluence.successfactors.com/display/PRODINFO/Role+Based
+Permissions .
 Recommendation
RBP is completely data-dependent. Therefore, engage customers as much as possible and as soon as possible
in RBP discussions, as they know their data best. In addition, train your customers and enable them to manage
the permissions themselves. Guiding customers so they have a complete understanding is critical to success.

36 CONFIDENTIAL Designing the RBP Configuration
5.1 Checking Available Permissions in a New Customer
Instance
Context
Depending on what modules are activated in the customer instance, different permissions are available to be
configured. To find out exactly what permissions can be granted:
Procedure
1. Log on to the customer instance.

2. Go to Administration Tools. In the Manage Employees portlet, select Set User Permissions.
3. In the Set User Permissions section, select Manage Permission Roles.
4. Click Create New.
5. In section 2 Permission Settings, click Permissions. On the left you can see the permission categories. If you
click on one of these links, you see the detailed permissions on the right.
5.2 Review Permissions in Existing Customer Instance
If you migrate a customer instance from the old permission framework to RBP, create a security permissions report
to review what permissions are set.
Log on to the customer instance and select Admin Tools Set User Permissions Security Permissions
Report .
5.3 Which modules are covered by RBP?
RBP controls the access to most modules. The page permissions (that is, what data and functionality appears on
the page) are partly controlled by RBP and partly controlled by other mechanisms, depending on the requirements
of the modules.
For some modules it is mandatory to use RBP. If several modules are in use and RBP is mandatory for one, you
must configure RBP for all modules. You cannot mix RBP with the old permission framework.

Designing the RBP Configuration CONFIDENTIAL 37
If multiple instances are used we recommend using either RBP or the old permission framework on all instances.
Although it's not a technical limitation - you can have RBP on one instance and the old permission framework on
other instances - it's better to go for one solution from a maintenance and governance perspective.
The following graphic provides an overview of where RBP is used and where other mechanisms are in place. In the
table below, you will find details on RBP coverage for each module.
Here are two examples which illustrate how other mechanisms then RBP control access to elements and functions
for some modules:
Goals
For Goals, you set the permission to access the goal plans and some other access permissions in RBP.

However, with that, the permissioned users are not allowed to create, edit or cascade goals. These permissions are
derived from the custom-specific goal plan xml file. This xml file specifies which roles (such as, employee, manager,
HR manager) are allowed to view and edit goals. The following table shows the part of the workbook where these
permissions are specified:
In addition, in the employee import file each employee is assigned to a dedicated manager and HR manager. Only
the HR manager determined here can see and edit fields in an employee's goal plan. It's a 1:1 relationship, so as a

consequence, it's not possible to grant multiple HR representatives access to a specific development plan. The
following shows an excerpt of such an employee import file:
Performance Management
Permissions to access the Performance Management Tab and to create a performance management form are
provided in RBP.
Who is involved in each workflow step is defined in a route map. Permissions to do changes, for example rate the
performance and potential, is hard coded in the corresponding form xml file. Both the rout map and the form xml
file use the predefined roles, such as E, EM, and EH. That is, ultimately the role a user has and the relationships
defined in the employee import file determine who is allowed to work on performance management forms.
Details on RBP Module Coverage

Module Is it covered in RBP? Controlled by RBP Not controlled by RBP
Admin Tools Everything within Admin Tools
Calibration ● Access to Calibration tab Within Calibration, specific

● Access to employees permissions grant read, write,
whom the user will see edit, and finalize authorization
within Calibration for individual sessions.

Career Access to Careers tab and Once the Career tabs and sub-
sub-tabs
tabs are permissioned under
RBP, all sub tabs, postings,
and so on, are visible. There
are no deeper permissions
available by RBP, the module,
or xml.
CDP User Permissions Permissions within Goal Plans,

such as creating, editing, or
● Access to development cascading goals.
tab
● Access to career work
sheet tab
● Access to development
plan template, career
worksheet template,
learning activity template
● Access to Career Devel
opment Plan (CDP)
Learning Activity Mass
Add
● Access to development
admin permission
Administrator Permissions
● Access to Import Devel

opment Goals
● Access to Manage Learn
ing Activity Catalogs
● Access to Manage Learn
ing Activity to Compe
tency Mappings
● Access to Manage Career
Path
● Access to Manage User
Relationship for Learning
Administrator and Educa
tional Representative
● Access to Manage Import
Learning Activity by Web
Service
Company Info Company Info menu is visible

for everybody
Compensation/Variable Pay ● Access to tabs and sub ● Permission within com

tabs within Compensa pensation forms
tion and Variable Pay ● RBP does not apply to
● Permission to read and compensation plan level
edit executive reviews

Employee Central Access to EC and page per

missions
RBP is mandatory
Employee Profile ● Access to Employee Pro

file (Live Profile Access)
● Field level permissions to
employee data
Goals ● Access to Goal tab Permissions within Goal Plans,

● Access to Allow Role to such as creating, editing, or
Create Group Goal cascading goals. However,
(Group Goal 2.0)
for/to whom the employee
● Access to Allow Role to
can create, edit, cascade goals
Assign Add Group Goal
is controlled by the target pop
2.0 to other Users
● Access to Execution Map ulation of the "Access to Goal
under Goal Execution Plans" permission item.
● Access to Meeting
Agenda under Goal Exe
cution
● Access to Status Report
under Goal Execution
● Access to Goal Plan(s)
● Administrator permis
sions
● Access to Import Goals
● Access to Import/Export
Goals library
● Access to Manage Config-
uration of Goal Execution

Home Page ● Everyone sees the home

page
● Items visible on the Home
Page are based on user’s
permissions to those indi
vidual items/portlets
● Administrators can ena
ble or disable out-of-the-
box portlets. When an
out-of-the-box portlet is
enabled, it will appear for
all users. Modules control
what content will appear
in the portlet, so this can
be a mix of RBP and non-
RBP controls depending
on the portlet. Adminis
trators can add custom
portlets and use dynamic
groups (outside of RBP)
to control who sees the
custom portlets.
Jam Access to Jam Permissions within Jam
Job Profile Builder 2.0 Access to Job Profile Builder

and page permissions
RBP is mandatory
Learning Access to Learning menu Permissions within the Learn

ing module
MDF Position Management Access to MDF Position Man

agement and page permis
sions
RBP is mandatory

Onboarding ● For corporate users (that Hiring managers automati

is HR and admins) in cally gain access to onboard
1308 we will pass a group
RBP is mandatory ing (it appears in the main
assignment that is cre
menu navigation) if one of
ated in RBP to onboard
ing admin. The onboard their team members is ac
ing admin then reads the tively being onboarded. This is
group assignment and not through RBP.
determines what content
in the compliance tool
should be exposed to the
user.
● Page permissions are a
mixture of manager dis
cretion and RBP. A man
ager gives new hires ac
cess to some information
before their first day on
the job. That includes
looking at the profiles of
their future team, bud
dies (mentors), and other
people the manager rec
ommends. However, RBP
controls what data from
the selected users the
new hires can see. The
new hires will not be able
to see other people or the
whole org of the corpora
tion.
Performance ● Access to Performance Permissions within forms

tab (that is, required fields)
● Access to Create Forms
Recruiting ● All features under Re ● Recruiting tab

cruiting Permissions in ● Any user with access to a
Permission Settings requisition for any reason
● Administrator permis has irrevocable access to
sions (allows the admin the Recruiting tab.
to give the user access to ● Form template permis
certain links in Admin sion grants access, but
Tools) there are also other ways
● The permission to create employees may have ac
forms and the reports cess. For example, if a
permissions are shared form is routed to them, if
with the other modules – they are added as an op
both are covered by RBP. erator to the form, or if
certain feature permis
sions are granted to them

Reports Menu – Dashboards Controlled by RBP: Cell and field level permissions
& Analytics are not adhered to in ad hoc
● Access to specific dash reports or dashboards, except
boards and reports under for Employee Profile (opt-in).
Analytics
● Access to target popula
tions the user will be able
to report on
Limited RBP control:
● For ad hoc reports, the

access to specific report
ing sub domain schemas
is controlled via RBP, but
access to specific reports
is done via “sharing”,
which is not controlled by
RBP. Sharing is user
based. Though if, for ex
ample an RCM report is
shared with a user that
does not have RCM sub
domain schema access,
then it will not run.
Reports Menu – Workforce Access to Workforce Analytics Permission controls within

Analytics WFA. There is a concept of
is controlled via the “Inform
RBP in WFA but it is a separate
Reports” permission in RBP.
RBP permission page within
WFA app and does not link
through to BizX RBP.

Succession ● Access to Succession tab Configuration of the 9 Box and

● Access to Succession Org Succession Org Chart. For ex
Chart, Succession Plan ample, if a client opts to in
ning, Matrix Grid (9-box)
clude gender or minority on
and Talent Search
these as a configuration deci
● Access to all Succession
sion, this will not honor RBP
admin functions, includ
ing Succession Manage settings that may have ex
ment, Position Set-up, cluded visibility of same.
Matrix Grid admin tools,
The same is true for talent
Sync Position Model
search. RBP limits who shows
● Beyond access to specific
succession features, RBP up, but does not respect field
also controls "target pop level permissions set up in
ulation" for users – which RBP.
users and what details
can be viewed by the log
ged in user. These in
clude:
● Position details of users,
which are controlled by
position specific permis
sion
● Field level details of posi
tions
● Ability to view users on
search results
matrix grid reports
succession org chart and
lineage chart
5.4 Recommendations and Best Practices
5.4.1 Special Requirement: Separation of Duties in RBP

Administration
You may require the capability to separate duties such that one group of administrators can define the permission
roles, while a different group of administrators can assign the roles to users. This requirement is also known as the
“four eyes principle”, meaning that at least two persons (four eyes) are required in order for a permission to
ultimately be assigned to a user.

Role-Based Permissions can allow for separation of duties by virtue of its ability to automatically assign a role to
users based on attributes about the user. One group of administrators set up the roles and the attribute-based
group definitions. Another group of administrators manages the employee profile data by assigning specific values
to individual users for a specific custom field. When the employees' values match a role assignment, the role is
granted to the user.
In summary, you can achieve Separation of Duties with the following process:
1. You create a Global Security Administrators group which has access to RBP. These global security
administrators define the roles and create groups based on values available in the custom field "Access Rights".
They assign the roles to the appropriate groups.
2. You create a separate group of administrators and allow them to edit the values in the user profile for the
custom field "Access Rights". These administrators do not need access to RBP. Instead, the administrators
control the assignment of users via criteria defined in employee profile.
5.5 Basic Roles
Some roles in general exist in each company, like, for example, Managers and HR Manager. These roles tend to have
similar permissions. We have listed the most common roles below along with their typical permissions. You could
use these to start the requirements discussions with your customers.
Even before the requirements session you could proactively configure these roles to give users access to the
system to test the configuration. These roles do not require specific groups. Therefore it is possible to create them
before you have created any groups.
However, in larger organizations some roles might be split up in more specific roles. For example, they do not have a
single manager role, but one manager role for each region because in each region they are allowed to see different
data.
Role Name Includes the following permissions…
Login ● Login permission

To have the login permission in a separate role allows the
admin to turn the system on and off as needed (for main
tenance, for example) without going into any other roles.
This can also be useful if a global organization wants to re
lease the system to a specific population (for example, in
specific country) at different time. Additionally, the login
permission should be included in the "System Admin All
Modules" role to make sure that they are not locked out ei
ther.
All users (what any user can do and see for all other users) ● Data any user can see about any other user
● Access to goal and development plan
● Careers tab permission
● Permission to navigate within the org chart
● Mobile access, if necessary

Role Name Includes the following permissions…
Employee self (what users can do and see for themselves) ● Data users can see about themselves (like employment
data or personal info)
● What background sections they can maintain / edit for
themselves
● Permission to create forms for themselves (depending on
the culture)
Managers (permissions granted to users who have at least one ● What data managers can see about their reports
direct report defining what they can do and see for their direct ● Permission to create forms for their reports
reports)
● Permission to create job requests
● Probably permissions to manage compensation for their
reports
● Permission to use succession and succession org chart
HR (permissions granted to HR staff) ● What data HR can see / maintain for their scope
● Permissions to create forms depending on the culture
● Permission to use succession, calibration and so on
● Permission to search for candidates or use talent search
System Admin All Modules (permissions granted to customer ● Permissions to do/see everything for everybody
admins)
Local Administrators ● Limited administration rights, for example, upload em

ployee data, create performance forms
5.6 Copying Roles and Groups between Test and Production

Systems
When you configure RBP, it is common to make changes first on the test instance. Only after successful testing you
copy the configuration to the production instance. As roles are dependent on the system configuration (for
example, which fields, forms, or reports are enabled), and groups are dependent on the employees and their data,
it is very important that test instance and production instance contain the same system configuration and
employee data.
To make sure that test and production instance are in sync:
● Ensure that your employee data file is synchronized between your test and production systems.
● Consider if there are data changes coming that would affect the ability to permission correctly (for example
organizational restructures). If so, you need to have that data available in the test instance if you want to
permission it now. In addition, the data will need to be in the production instance by the time the permissions
are ready to be copied to the production instance.
● Consider if there are system configuration differences between your test and production systems. For example,
are there are more features enabled in the production instance than in the test instance? Compare the data
models to make sure the instances match. You can ignore the permissions sections of the data models at this
point which do not apply in RBP systems. Only check for data elements.
Depending on how much is out of sync, you may need to have the production instance copied to the test instance
(possibly using the instance sync tool) or you may be able to work around it.

If, for data protection reasons, it is not possible to update the test instance with productive data, you must at least
make sure that all elements actually exist in the test instance. Otherwise it is not possible to fully implement RBP
on the test instance so that it can then be copied to the production instance.

6 Preparing the Instance
6.1 Ensuring that Test Instance and Production Instance are

In Sync
When you implement and configure RBP, you do this first on the test instance. Only after successful testing you
copy the configuration to the production instance. For this reason, it is very important that test instance and
production instance contain the same data.
To make sure that test and production instance are in sync:
● Request the client to refresh the employee data file in the test instance with production data.
● Ask the client if there are data changes coming that would affect the ability to permission correctly (for
example organizational restructures). If so, they need to have that data available in the test instance if they
want to permission it now. In addition, the data will need to be in the production instance by the time the
permissions are ready to be copied to the production instance.
● Compare the Provisioning to see if there are more features enabled in the production instance than in the test
instance. Compare the data models to make sure the instances match. You can ignore the permissions
sections of the data models at this point which do not apply in RBP systems. Only check for data elements.
Depending on how much is out of sync, you may advise the client to have the production instance copied to the test
instance (possibly using the instance sync tool) or you may be able to work around it.
If, for data protection reasons, it is not possible to update the test instance with productive data, you must at least
make sure that all elements actually exist in the test instance. Otherwise it is not possible to fully implement RBP
on the test instance so that it can then be copied to the production instance.
6.2 Configuring Fields for Setting up Permission Groups
When you create groups, you select the group members according to specific selection criteria. You can configure
which selection criteria should show up on the screen where you define permission groups.
6.2.1 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.

50 CONFIDENTIAL Preparing the Instance
Standard Fields allowed as filters in Permission Groups
benchStrength custom12 keyPosition
citizenship custom13 location
city custom14 married
country custom15 minority
custom01 dateOfBirth nationality
custom02 dateOfPosition newToPosition
custom03 department reasonForLeaving
custom04 division riskOfLoss
custom05 ethnicity state
custom06 External Source Channel (Only available Team View

if Learning is enabled.)
custom07 timeZone
futureLeader
custom08 title
gender
custom09 username
hireDate
custom10 zipCode
impactOfLoss
custom11 jobLevel
jobCode
6.2.2 How do you specify which 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 of the
possible fields listed in the table above.
 Recommendation
For very large organizations (above 100,000 employees) it helps performance to limit the number of fields used
to define groups. At the very least, if a customer does not intend to use all available fields, remove the ones you
are sure are not needed.
Example XML snippet:
<dg-filters>
<my-filter>
<standard-element-ref refid="department"/>
<standard-element-ref refid="location"/>
</my-filter>
<permission-group-filter>
<standard-element-ref refid="division"/>
<standard-element-ref refid="custom05"/>

Preparing the Instance CONFIDENTIAL 51
</permission-group-filter>
</dg-filters>
The XML tags above work as follows:
The <dg-filters> tag has two sub-tags, <my-filter> and <permission-group-filter>:
● <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). In Employee Central, the allowable HRIS fields are documented in the Employee
Central Master Implementation Guide: http://service.sap.com/%7Esapidb/012002523100008617742014E/
SF_EC_Master_Impl.pdf .
● <my-filter>
Used to specify the fields used in the My Groups feature, which is a separate, unrelated feature. Contact your
SuccessFactors representative for more information.

52 CONFIDENTIAL Preparing the Instance
7 Conducting Tests
After you have set up all groups and roles and granted the roles, test the permissions thoroughly to find out
whether the employees have access to everything they need.
You can only conduct reliable tests if the data is complete in the test instance. Roles which require dedicated
groups cannot be tested otherwise. If the data is not there to populate the granted users group or the target users
group, the tests will fail. The easiest way would be to update the test instance with production data. However, if this
is not possible due to data protection reasons, a set of real sample data is required to conduct valid testing.
Testing roles which do not require specific groups but make use of relationships is easier. You just need test users
for all hierarchy levels, like manager, HR Manager, and employee. Double check the hierarchy, then log on as a
specific test user and double check the permissions.

Conducting Tests CONFIDENTIAL 53
8 RBP Ad Hoc Reports
Use ad hoc reports to understand an RBP configuration.
Reports help to troubleshoot and understand the permissions that have been configured. Ad Hoc reports are an
aggregate of all the RBP data in your system. You can access this info and share it using the following output
formats: PDF, Excel, PPT, and CSV.
8.1 Enabling RBP Spreadsheet (RDF) Reports
Context
For standard spreadsheet reports, we have RBP versions available which must be enabled for the customer.
Procedure
1. If the RBP versions of the RDF files are not loaded yet into the customer instance, you must load them in
provisioning. Download the RBP versions of the standard RDF Reports from SVN at http://cvs/viewvc/svn/
modules/V4/trunk/au-V4-SFV4Client/src/content/cannedReportRDF/RBP%20enabled%20spreadsheet
%20reports/
2. Log on to the Provisioning Tool.
3. Go to Provisioning Managing Spreadsheet Reports Import/Update/Export Spreadsheet Report

Templates .
4. Upload the report templates.
5. If the customer used the old permission framework before, there are probably old spreadsheet reports that
don't work with RBP. Make sure to remove these reports.

54 CONFIDENTIAL RBP Ad Hoc Reports
Next Steps
 Note
If customers have custom reports, they will have to engage Premium Reporting to convert their reports to the
RBP system, with charges associated. Once those RDFs are available, they can be loaded into the customer's
instance.
8.2 Enabling Ad Hoc Reports with Cloud Support
Ad hoc reporting can help you to understand your role-based permissions configuration.
Context
 Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP Cloud
Support.
Procedure
1. Log on to the Provisioning tool and go to Company Settings Additional Adhoc Sub domain Schemas
Configuration .
2. When ad hoc reports are enabled, go to Analytics Reporting Ad Hoc Reports . You can create the
following reports:

RBP Ad Hoc Reports CONFIDENTIAL 55
○ RBP User to Role Report
○ RBP Permission to User Report
○ RBP User to Group Report
○ Permission Roles Report
8.3 Granting Permissions to Reports
Grant ad hoc reporting permissions to your SuccessFactors Admin.
Context
Once Role-Based Permissions are enabled and Cloud Support has created the Super Admin role, complete the
following task to grant access to RBP ad hoc reporting.
Procedure
1. As a Systems Admin, Select Manage Permission Roles, in the Admin Center.

2. Select the Systems Admin role.
The permission role screen will show the role name and description.
3. On the Permission Role Detail screen, select Permissions.
4. When the Permission Settings screen displays, select Report Permissions from the list.
5. When the report permissions displays, enable Create Reports and Run Reports by selecting the check boxes.
6. For Ceate Reports and Run Reports permissions, select Other.
7. When the list of reports activates, multi select following reports:
• RBP User to Role Report
• RBP Permission to User Report
• RBP User to Group Report
• Permission Roles Report

Selecting these reports will allow your SuccessFactors admin to create and run RBP ad hoc reports.
8. Click Done.
9. When the Permission Role Detail screen displays again, scroll to theGrant this role to section and search for the
granting group.
10. When the granting group displays, select Edit Granting
11. When the Grant this role to screen displays, select Super Admin as the granting group.
12. In the Target Group, select Everyone.

13. Click Done.
14. Click Save Changes to complete the process. Log out and log back into the system for your changes to reflect.
8.4 Creating a Permissions Report
The permissions report displays information about all the permissions that are configured in your system.
Context
Setting up this permissions report gives you configuration information for all your configured permissions.
Procedure
1. Go to the Reporting page in Analytics and choose Create New Report.
To access Reporting the admin user must have the necessary permissions granted.
2. Select the RBP Permission to User Report.

RBP Ad Hoc Reports CONFIDENTIAL 57
3. Define the report by selecting the columns desired. From the list select, Role Name, Granted Population, Target
Population, and Permission.
4. Click Done and save the report.
8.5 Setting Up a Report with Permission Filters
Use this report to filter for permissions when running reports.
Context
Running this report, allows you to specify a permission to be filtered for and can help you identify how the
permission was granted to a user.
Procedure
1. Follow the steps 1- 3 of the above procedure.

2. Click Filters and then click Refine Criteria
3. Choose Permission as filter.
On the By My Selection tab, choose Select All and mark the checkbox User Prompted.
4. Click Done and save your changes.

9 Troubleshooting
Context
If you find that users have access to applications or data they should not have, we recommend the following steps:
Procedure
1. Run the View User Permission report to determine how - through which role - the permission was granted to
the employees. For details see How can you check the permissions assigned to a user? [page 59]
2. If that does not clarify how/why they have that permission or creates concern about where else this permission
is visible, then use the RBP Permission to User Report with the Single Permission Filter to validate what other
groups have access to this permission. For details see How can you run an ad hoc report? [page 60]
9.1 How can you check the permissions assigned to a user?
Procedure
1. Go to Administration Tools.
2. In the Manage Employees portlet, select Set User Permissions.
3. In the Set User Permissions section, select View User Permissions.
4. In the Advanced Search, enter the user name.
5. Click View Permission next to the user name.
A list of permissions is displayed along with the roles that grant those permissions.

Troubleshooting CONFIDENTIAL 59
6. To learn more about the roles, click the pop-up window icon next to any role name.
9.2 How can you run an ad hoc report?
Context
Procedure
1. Go to the Reporting page in Analytics and choose Ad Hoc Reports.

2. Open the menu next to the report name and choose Run Report.
3. On the Execute Permission to User… screen, open the Take Action menu and choose Edit.
4. Choose By My Selection and select the permission you are interested in.

60 CONFIDENTIAL Troubleshooting
5. Click OK and then Generate Report.
6. In the report, you can now see exactly to which role(s) the permission is granted.
9.3 Cross Domain Ad Hoc Reporting Between the RBP and

Employee Central Domains
The cross domain ad hoc report capability allows Administrators to run reports between the Role-Based
Permission (RBP) domain and Employee Central (EC) domain. RBP reports are included in the drop-down menu
when selecting the Cross Domain Report Definition types.
Administrators can create Cross Domain Reports to join RBP and Employee Central data. Person and Employment
is the EC domain information that is included and the tables are joined using the user_sys_id key.

9.4 How do you run a user search
User Role Search can search the roles granted to specific users for a specific permission and a target user. When
some users get some permissions on some target users that should not be granted, the administrator can use this
tool to find which role grants the permission so they can update the permission settings.
● This tool does not support MDF RBP permission as search criteria.
● This tool does not support Inactive Internal User or TBH user to be selected as Target User.
● This tool does not support External User.
3. In the Set User Permissions section, select User Role Search.

4. In the Selection session of the tool, enter Access Users. You can select at most 2 access users.
5. Select Permission Category and one Permissions. If the permission needs target population, you can optionally
select one target user.
6. Click Search Roles Button. The search result will display all roles that grant this permission and target user to
the access users. If the target user field is empty, the search result will not consider target user. If a result you
expect to see is not showing up, it may be because there are back-end update jobs still running.
7. On the Result session, you can click on the role name to see role detail. On the role detail page, the grant rules
that grant the selected access user and target user will be highlighted in the “Grant this role to …” session.

How can you 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.
3. In the Set User Permissions section, select User Role Search.
4. In the Selection session of the tool, enter the Access Users whose roles you are comparing.
5. Click 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." In the following example, you can
see that the user "cgrant" has permission to view "Impact of Loss" data, due to her roles as a manager and
administrator. The user "jreed" is not assigned to any role that allows him to view this information.
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. In the following example, you can see that although both user "cgrant" and
user "dsharp" are managers, only user "cgrant" has permission to view "Impact of Loss" data for user
"vstokes". This is because, in this example, the manager role has a target permission group of "All Direct

Reports" and "vstokes" is a direct report of "cgrant".

10 Copying RBP Configuration to Production
Instance
After the tests are complete and you solved all issues, you copy the RBP configuration to the production instance.
Two tools are available for this task: in the application under Admin Tools and in Provisioning.
The tool provided under Admin Tools has the advantage that you can perform copies across data centers.
Using the Instance Synchronization under Administration Tools
1. Enable the synchronization in Provisioning:

1. Log on to Provisioning and select the company.
2. Click Instance Synchronization Company Permissions.
The Edit Objects screen opens.
If you don't see this link, instance synchronization is not yet enabled for the company. For information
about enabling instance synchronization, see the Instance Sync Guide available at http://
confluence.successfactors.com/display/PRODINFO/Platform+Configuration+Guide+-+Instance+Sync .
3. Make sure that RBP Roles and RBP Groups are selected.

66 CONFIDENTIAL Copying RBP Configuration to Production Instance
2. Grant the required permissions to the appropriate users:
1. Log on to the instance and choose Admin Tools.
2. Choose Set User Permissions Manage Permission Roles .
3. Select the role which will be responsible for synching data between instances and choose Take action
Edit .
4. Under Permission Settings, click Permissions….
5. Click Data Management and select Sync RBP Permission Roles and Sync RBP Permission Groups.
6. Log out and back in.
3. Copy roles and groups:
1. Choose Admin Tools Synchronize Instance Configurations .
The configuration sync wizard starts.

Copying RBP Configuration to Production Instance CONFIDENTIAL 67
2. Follow the wizard to select the target instance, and the groups and roles to be copied.
Tips for copying groups:

○ The user (username) who created the group in the source instance must also be a user in the target
instance for the sync of the groups to be successful.
○ You are asked if you want to overwrite the existing groups in the target instance. If you choose not to
overwrite and there is a group in the target instance with the same name, the group will not copy to
target instance.

Tips for copying roles
○ To successfully copy roles, you first have to sync all attached groups with the target instance.
○ Templates, families, roles, picklists and further data associated with the roles in the source instance
need to exist in the target instance for roles to be successful
3. Choose Test Sync and evaluate the results of the test run.
If the sync was successful, you will see in the UI that the Add & Update Count has been updated with the
number of groups copied.
In the download report you will see a success message.
If the sync was not successful, you will see in the UI that the Failed Count has been updated.
In the downloaded report, you will see the reason for the failure - for example, that the user does not exist
in the target instance.
4. If the test run was successful, then choose Run Sync Now to actually copy the groups and roles.

Copying RBP Configuration to Production Instance CONFIDENTIAL 69
Using the Copy Function in Provisioning
1. Log on to Provisioning and click Copy Permission Roles from Another Instance.
2. First, do a dry run to check whether all prerequisites are fulfilled for copying roles or groups. Only after a
successful dry run, select Copy RBP Configuration.
3. Select the target instance and either choose to copy all groups and roles or select specific roles or groups to be
copied.
When you click Done, a job is scheduled which will execute the copy.

11 Using the Check Tool
Use the check tool to find potential problems and errors in your configuration before you call support about an
issue.
Prerequisites
Enable Metadata Framework (MDF). Most customers already use MDF.
Assign Access Check Tool and Allow Configuration Export to your role in Role Based Permissions (RBP).
● Access Check Tool authorizes users to access the tool.

● Allow Configuration Export authorizes users to attach configuration information to a ticket.
Procedure
1. Go to Admin Center.
2. In the tools search field, type Check Tool.
3. In Application, select the application you want to check.
 Tip
All Applications runs checks in all your applications.
For example, to run checks for Time Off, select Time Off.
You see the checks for the application you selected.

4. Click the check the box at top left in the table to run all checks.
5. If you want to run only some checks, select them individually.
 Tip
To understand what a check does, right click the Check ID. The system then displays some information on
the check.
6. Click Run Checks to check your applications for the checks you selected.
Next Steps
Evaluate the results and resolve the issues. If you encounter an error you cannot resolve, contact Support by
creating a ticket.

Using the Check Tool CONFIDENTIAL 71
Benefits of the Check Tool [page 72]
The SAP SuccessFactors check tool helps you identify and resolve issues when your system doesn’t work
as you expect.
Check Results [page 72]

After you run checks in the check tool, it returns the results of the check so that you can resolve issues that
it found.
Creating Support Tickets from the Check Tool [page 73]

When the check tool reports a serious issue, you might need to contact Support. You can create a Support
ticket from within the check tool.
11.1 Benefits of the Check Tool
The SAP SuccessFactors check tool helps you identify and resolve issues when your system doesn’t work as you
expect.
If your SAP SuccessFactors applications are behaving in unexpected ways, it is likely that it has a configuration or
data conflict: you have some data that is inconsistent or a configuration error. The check tool quickly identifies
these types of problems so that you can avoid support tickets. You might still need to create a support ticket if the
problem is severe, but even in severe cases, the check tool can save you time because it can export the results of
the check and your configuration for support. The support engineer, therefore, can identify the issue more quickly.
When you run the check tool, you see:
● A list of issues in your configuration or data and the severity of each issue.
● A solution or recommendation to address the issue.
11.2 Check Results
After you run checks in the check tool, it returns the results of the check so that you can resolve issues that it
found.
To see the results of the checks, look in the Results column. If you run the checks multiple times to see how you are
resolving issues, look in the Previous Result column to compare the current results to previous results.
Possible Results of Check Tool
Result Action
No issues found If the tool cannot find issues, you see a green check mark the Result.

72 CONFIDENTIAL Using the Check Tool
Result Action
Issues found If the tool finds issues, it reports the number of issues and a yellow warning icon or a red alarm
icon.
● The yellow icon indicates a low severity issue. The system proposes a solution.
● The red icon indicates a high severity issue. You must take action, which could include creat
ing a Support ticket.
Related Information
Creating Support Tickets from the Check Tool [page 73]
11.3 Creating Support Tickets from the Check Tool
When the check tool reports a serious issue, you might need to contact Support. You can create a Support ticket
from within the check tool.
Prerequisites
Run the check tool. You can find the check tool by going to Admin Center Check Tool . You create the ticket
from the results page of the tool
Procedure
1. On the results page, look in the Result column for the errors you want to report on.
You usually contact Support for high severity issues not low severity issues.
2. Click the error in the result to open the Detailed Result.
 Note
If you cannot click the error, expand the list of checks from the Description column, and then click the error
from the Result column.
3. In Detailed Result Need Assistance? , copy the component ID.
For example, LOD-SF-EC is the component ID for Employee Central.

4. Create a customer incident in the relevant category.

Using the Check Tool CONFIDENTIAL 73
5. When you create the ticket, paste the component ID into the ticket.

74 CONFIDENTIAL Using the Check Tool
12 RBP Configuration Checks
12.1 Does the Everyone Group Exist?
The CheckEveryoneGroup test validates that the Everyone group exists.
The Everyone group contains all employees in your system and is automatically created when RBP has been
enabled by your super admin. If the Everyone group has not been created in your system, you may experience
errors when attempting to create groups for other users in your system. The CheckEveryoneGroup test validates
that the Everyone group exists.
When you run this check, if the result is true, the Result section of the Check Tool displays the names of the User
Types that do not have the Everyone group. This may be either the Employee or External Learner user type.
Check ID Check Name Recommended Solution
CheckEveryoneGroup Verify if the Everyone Group Exists Since the Everyone group is created
when you enable RBP in your system,
disable RBP and enable RBP.
12.2 Do Roles Exist Without Groups or Users?
The CheckRoleRuleAccessGroupUser test validates if your system contains roles that exist without access
permission users or groups.
In your system, each role should contain access users or groups. When users or groups have not been assigned to
a role, run time exceptions may occur. These exceptions can occur anytime the system tries to execute access
permissions in your system.
When you run this check, if the result is true, the Result section of the Check Tool displays the names of the roles
that do not have access users or groups assigned to the role.

RBP Configuration Checks CONFIDENTIAL 75
CheckRoleRuleAccessGroupUser Verify if Roles Exist that are not Associ Execute any of the following solutions if
ated with Access Permission Groups or you have errors in your system after run
Users ning this check.
• Associate Permission groups or users

that you want to grant this permission
role to.
• Deactivate the rules that are not cur

rently associated with any permission
groups or users.
• Delete any rules that are not associated

with permission groups or users.
12.3 Do Roles Exist Without Target Population?
The CheckRoleRuleTargetGroup test validates if there are any roles in your system where target population hasn't
been defined.
Roles in your system contain some permissions that require target population to be defined and other permissions
that do not require target groups. For permissions that require a target group, you must define a target group for
the role. When you don’t define a target group, you may experience errors in your system when the system
attempts to calculate target group permissions.
that do not have target groups assigned to the role.
CheckRoleRuleTargetGroup Verify if Roles Exist Without Target Popu Execute any of the proposed recommen
lation Defined. dations below for the roles listed in Re
sults section:
• Specify the target population for whom

granted users have permission to access.
• Deactivate the rules that are not cur

rently associated with any target popula
tion.
• Delete any rules that are not associated

with a target population.

76 CONFIDENTIAL RBP Configuration Checks
12.4 Do Group Names Exceed 1000 Characters?
The CheckAccessGroupNameLength test validates if the total length of access group names that are associated
with a rule exceeds 1000 characters.
When you associate rules to your roles it’s important that you do not exceed 1000 characters for each rule. While a
rule can contain several groups and a role can contain several rules, each rule should not contain 1000 or more
group name characters. Meaning, the names of your groups, for each rule should not exceed 1000 characters.
Access groups with 1000 or more characters may cause errors or slow down your system.
that contain 1000 or more characters in total length.
CheckAccessGroupNameLength Verify if the Access Group Names Associ Execute any of the following solutions if
ated with a Rule Exceeds 1000 Charac you have errors in your system after run
ters. ning this check.
• For each role in the Results section, re

view the highlighted rules.
• Create a new access group that in

cludes all the access groups associated
with a rule. Or condense the current ac
cess groups into fewer access groups.
• Replace the current access groups with

the newly created access group.
• You can also rename the associated ac

cess groups so that the total number of
characters does not exceed 1000.
12.4.1 What are Rules in RBP?
Rules in RBP are used to define access to permissions in your system.
Rules are defined by determining which permission roles you’ll assign to your groups or users. From the Permission
Role Detail screen in your system, each rule is represented by a row that contains your list of granted users or
groups and the associated target group. Depending on the complexity of the roles and access or target group
assignments, your roles could have various combinations of access and target group rules.
From your permission role detail screen, where you manage your permission roles, each row represents a rule and
each rule can have multiple access and target group associations, as detailed in the display.

12.5 Do Target Group Names Exceed 1000 Characters?
The CheckTargetGroupNameLength test validates if the total length of target group names that are associated with
a rule exceeds 1000 characters for a role.
When you associate rules to your roles it’s important that you do not exceed 1000 characters for each rule. While a
rule can contain several groups and a role can contain several rules, each rule should not contain 1000 characters
or more target group name characters. Meaning the names of your targer groups for each rule should not exceed
1000 characters. Target groups with 1000 or more characters may cause errors in your system.
that contain target group names with 1000 or more characters in total length.
CheckTargetGroupNameLength Verify if the target group names associ Execute following solution if you have er
ated with a rule exceeds 1000 characters rors in your system after running this
check.
1. Create a new target group that includes

all the target groups associated with a
rule.
2. Or condense the current target groups

into fewer target groups.
3. Replace the current target groups with

the newly created target group.
You can also rename the associated tar

get groups so that the total number of
characters does not exceed 1000.

12.6 Does a User Have the Same Permission More Than 30
Times?
The CheckUserPermissions test verifies if there are employees in your system who have been granted the same
permission more than 30 times.
When employees in your system are granted with the same permission multiple times by granting them roles that
contain duplicated permissions, it may cause your system some issues, such as system slowdowns or errors.
When you run this check, if the result is true, the Result section of the Check Tool displays the user names,
permission names, the number of times the user has been granted the permission, and the role names associated
with the permission. Additionally, by clicking the user names, you can review more records that are associated with
each user.
CheckUserPermissions Verify if a user has been granted the Execute any of the following solutions if
same permission more than 30 times you have errors in your system after run
ning this check.
• Determine roles defining the Permis

sion Basic Roles first including the most
common settings for all users. This is ex
pected to be the Role Everyone, Em
ployee, Manager, HR and Administrator. If
a permission has been granted to every
one, it never needs to be repeated again
in another role. A user in multiple groups
gets the combined permissions of all
groups they are a member of.
• For additional roles, work on an excep

tion basis and include only the unique ex
tra permissions that the role should have
beyond other roles.
• Avoid Duplication of permissions across

roles.
12.7 Does a Role Have More Than 100 Rules?

The CheckRulePerRole test validates if there are more than 100 rules associated with a role.
Rules are defined when you assign access groups and target groups to a role. While you might have several rules
defined for one role, it’s important to ensure that the number of rules for a role does not exceed 100. That means,
ensure that each row that defines access and target groups does not exceed 100 rules. When defining group access
rules for the roles in your system, it’s most efficient to break up rules otherwise, you may experience issues in your
system.

When you run this check, if the result is true, the Result section of the Check Tool displays role name and the
number of rules associated with the role.
CheckRulePerRole Verify if the number of rules associated Execute any of the following solutions if
with a role exceeds 100 you have errors in your system after run
ning this check.
• Minimize the number of rules by com

bining them into fewer rules and then re-
associate to the role.
• In case you have specific needs and you

are not able to combine the rules, split
them in different new permission roles
that do not exceeds 50.
12.7.1 What are Rules in RBP?
Rules in RBP are used to define access to permissions in your system.
Rules are defined by determining which permission roles you’ll assign to your groups or users. From the Permission
Role Detail screen in your system, each rule is represented by a row that contains your list of granted users or
groups and the associated target group. Depending on the complexity of the roles and access or target group
assignments, your roles could have various combinations of access and target group rules.
From your permission role detail screen, where you manage your permission roles, each row represents a rule and
each rule can have multiple access and target group associations, as detailed in the display.

13 Running the RBP Diagnosis Tool
The Role-Based Permissions (RBP) Diagnosis Tool generates a report, in one click, that highlights potential risks for
the specific RBP configuration settings in the test and production instances.
This tool is available once RBP functionality is enabled on the Provisioning screen. The tool's Run button is
displayed in this section of the provisioning screen and is not accessible by customers.
SAP Cloud Support (CS), Professional Services, or Implementation Partners can click the Run button to perform
back-end checks on the Role and Group configurations in the customer instance. Upon completion, the report
automatically opens in a new browser window. The information contained in the report can be shared among
internal SAP SuccessFactors teams to determine improvements to the RBP configuration settings.
 Remember
As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP Cloud
Support.
This report contains three columns: Description, ResultSet, and Suggestion.
● Description: Report name for a specific type of back-end system RBP check.
● ResultSet: Counts and USERS_SYS_ID information gathered during the check. If this column is empty for a
row, then there are no particular concerns for this check. If the column has an entry in a row, then see the
suggestion notes.
● Suggestion: Hard coded suggestions with best practices for solving potential configuration errors.

Running the RBP Diagnosis Tool CONFIDENTIAL 81
Important Disclaimers and Legal Information
Hyperlinks
Some links are classified by an icon and/or a mouseover text. These links provide additional information.
About the icons:
● Links with the icon : You are entering a Web site that is not hosted by SAP. By using such links, you agree (unless expressly stated otherwise in your agreements
with SAP) to this:
● The content of the linked-to site is not SAP documentation. You may not infer any product claims against SAP based on this information.
● SAP does not agree or disagree with the content on the linked-to site, nor does SAP warrant the availability and correctness. SAP shall not be liable for any
damages caused by the use of such content unless damages have been caused by SAP's gross negligence or willful misconduct.
● Links with the icon : You are leaving the documentation for that particular SAP product or service and are entering a SAP-hosted Web site. By using such links, you
agree that (unless expressly stated otherwise in your agreements with SAP) you may not infer any product claims against SAP based on this information.
Beta and Other Experimental Features

Experimental features are not part of the officially delivered scope that SAP guarantees for future releases. This means that experimental features may be changed by SAP at
any time for any reason without notice. Experimental features are not for productive use. You may not demonstrate, test, examine, evaluate or otherwise use the
experimental features in a live operating environment or with data that has not been sufficiently backed up.
The purpose of experimental features is to get feedback early on, allowing customers and partners to influence the future product accordingly. By providing your feedback
(e.g. in the SAP Community), you accept that intellectual property rights of the contributions or derivative works shall remain the exclusive property of SAP.
Example Code
Any software coding and/or code snippets are examples. They are not for productive use. The example code is only intended to better explain and visualize the syntax and
phrasing rules. SAP does not warrant the correctness and completeness of the example code. SAP shall not be liable for errors or damages caused by the use of example
code unless damages have been caused by SAP's gross negligence or willful misconduct.
Gender-Related Language
We try not to use gender-specific word forms and formulations. As appropriate for context and readability, SAP may use masculine word forms to refer to all genders.

82 CONFIDENTIAL Important Disclaimers and Legal Information
Important Disclaimers and Legal Information CONFIDENTIAL 83
www.sap.com/contactsap
© 2018 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.
Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.
SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.
Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.
THE BEST RUN

SF RBP Impl PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

SF RBP Impl PDF

Încărcat de

Drepturi de autor:

Formate disponibile

IMPLEMENTATION GUIDE | CONFIDENTIAL

SAP SuccessFactors Foundation

Implementing Role-Based Permissions

THE BEST RUN

2 What are Role-Based Permissions?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

4 Initial Setup Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5 Designing the RBP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

6 Preparing the Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Implementing Role-Based Permissions

8 RBP Ad Hoc Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .54

10 Copying RBP Configuration to Production Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

11 Using the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .71

12 RBP Configuration Checks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

13 Running the RBP Diagnosis Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

Implementing Role-Based Permissions

What's New Description More Info

What's New Description More Info

Information about the Check Tool and

What's New Description More Info

There were no updates to this document

Implementing Role-Based Permissions

What's New Description More Info

There were no updates to this document

What's New Description More Info

There were no updates to this document

What's New Description More Info

Implementing Role-Based Permissions

What's New Description More Info

There were no updates to this document

What's New Description More Info

What's New Description More Info

What's New Description More Info

Implementing Role-Based Permissions

Implementing Role-Based Permissions

Implementing Role-Based Permissions

Open this video in a new window

Permission Groups [page 10]

Permission Roles [page 16]

Permission Role Assignments [page 21]

Implementing Role-Based Permissions

Creating Static Permission Groups [page 10]

Creating Dynamic Permission Groups [page 14]

View, Edit, Copy, and Delete Permission Groups [page 16]

2.1.1 Creating Static Permission Groups

Implementing Role-Based Permissions

1. In the Admin Center, search for Manage Permission Groups.

Implementing Role-Based Permissions

Implementing Role-Based Permissions

1. In the Admin Center, search for Manage Permission Groups.

The Permission Group screen displays.

Entering keywords in the search field displays user names.

Each user you select automatically displays in the right pane.

The users you selected are added to the group immediately.

Implementing Role-Based Permissions

1. In the Admin Center, search for Manage Permission Groups.

The Permission Group screen displays.

The list of users updates immediately.

2.1.2 Creating Dynamic Permission Groups

1. In the Admin Center, search for Manage Permission Groups.

The Permission Group page opens.

Implementing Role-Based Permissions

The number of people pools in a group is limited to three.

Implementing Role-Based Permissions

Employee Central Only: Relationship Types for Global As

● Import standard spreadsheet reports to the customer in