Implementation Guide CONFIDENTIAL

SAP SuccessFactors Foundation

Document Version: Q2 2018 – 2018-05-07

Implementing Role-Based Permissions

Content

1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1 Concept of Role-Based Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Implementation Sequence. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11

3 Initial Setup Tasks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1 Creating a Super Administrator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2 Enabling RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3 Refreshing RBP after Changes in Provisioning Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.4 Granting Permissions to Manage RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5 Granting Yourself and Project Team Members All Privileges. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Designing the RBP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Checking Available Permissions in a New Customer Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2 Review Permissions in Existing Customer Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3 Which modules are covered by RBP?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 Recommendations and Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
General. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .27
Special Requirement: Separation of Duties in RBP Administration. . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.5 Basic Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.6 Copying Roles and Groups between Test and Production Systems. . . . . . . . . . . . . . . . . . . . . . . . . . . . .30

5 Preparing the Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.1 Ensuring that Test Instance and Production Instance are In Sync. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .32
5.2 Configuring Fields for Setting up Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
What Fields Are Available?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
How do you specify which fields to use?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .33

6 Setting up Groups and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

6.1 Creating Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Dynamic Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
Static Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.2 Creating Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Creating a New Role for External Users. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Configuring a JAM Private Role to enable full search in Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
6.3 Granting Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .45
Using Relationships to Grant Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Specifying the Hierarchy Depth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Implementing Role-Based Permissions

2 CONFIDENTIAL Content
6.4 Granting Permissions for MDF Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
6.5 View, Edit and Copy Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6.6 View, Edit and Copy Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Running the RBP Diagnosis Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Implementing Role-Based Permissions

Content CONFIDENTIAL 3
What's New in This Guide

The most recent changes made to this guide are listed below.

Q2 2018

The following table summarizes changes to this guide for the Q2 2018 release.

What's New Description More Info

There were no updates to this document

in Q2 2018.

Q1 2018

The following table summarizes changes to this guide for the Q1 2018 release.

What's New Description More Info

There were no updates to this document

in Q1 2018.

Q4 2017

The following table summarizes changes to this guide for the Q4 2017 release.

What's New Description More Info

There were no updates to this document

in Q4 2017.

Implementing Role-Based Permissions

4 CONFIDENTIAL What's New in This Guide
Q3 2017

The following table summarizes changes to this guide for the Q3 2017 release.

What's New Description More Info

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 Tar­ See the Granting Permission Roles topic
Target Population. get Population when granting permission for more information.
roles for external Learning users.

Q2 2017

The following table summarizes changes to this guide for the Q2 2017 release.

What's New Description More Info

There were no updates to this document

in Q2 2017.

Q1 2017

The following table summarizes changes to this guide for the Q1 2017 release.

What's New Description More Info

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
main and Employee Central (EC) domain. Domains [page 61]

Implementing Role-Based Permissions

What's New in This Guide CONFIDENTIAL 5
Q4 2016

The following table summarizes changes to this guide for the Q4 2016 release.

What's New Description More Info

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
71]
highlights all potential risks for the spe­
cific RBP configuration settings in the
customer instance.

Q3 2016

The following table summarizes changes to this guide for the Q3 2016 release.

What's New Description More Info

New button to add users to the Static Added the procedure to use the new Add Static Permission Groups [page 37]
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 Groups [page 37]
Static Permission Group Delete button for the Static Permission
Group.

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 43]

Implementing Role-Based Permissions

6 CONFIDENTIAL What's New in This Guide
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.

1.1 Concept of Role-Based Permissions

Understand the concept of role-based permissions and check out some examples of how you might use RBP to
control access to user information in your system.

The main elements in RBP are permission groups and permission roles.

What are Role-Based Permissions?

Role-Based Permissions (RBP) manage the permissions in the SAP SuccessFactors HCM Suite. RBP controls
access to the applications and what users can see and edit. It's a suite-wide authorization concept that applies to
the majority of the SAP SuccessFactors products.

RBP does not cover any permissions that are managed via templates. The permissions continue to be driven by the
code in the form/plan templates for the following:

● Goal Plan Permissions

● PM/360 Review Form Permissions
● Development Plan Permissions
● Recruiting Permissions

Implementing Role-Based Permissions

Introduction CONFIDENTIAL 7
RBP features include:

● Administrator definable roles

● Automation of permissions assigned to users
● Definition of user access based on employee attributes, hierarchies and relationships, and exclusion rules
● Auditing of changes to security (who, what, when)
● Copy permission configuration between systems

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

What are permission groups?

There are two main elements in RBP: Permission Groups and Permission Roles. 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".

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.

What are permission roles?

There are two main elements in RBP: Permission Groups and Permission Roles. A role is a set of permissions. As
such, a permission role controls the access rights an employee or group of employees is given in order to the
access the application or employee data. Role-based permissions allow you to grant a role to a specific employee, a

Implementing Role-Based Permissions

8 CONFIDENTIAL Introduction
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.

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

How are groups and roles connected?

While roles define what is allowed, the groups define who is allowed to do it (granted users) and for whom (target
users). This graphic illustrates the principle:

Once a role is defined, you grant the role to one or more groups of users represented by the circles on the left. Then
you restrict the granted users to perform the role on target users. For example, you may decide that managers (the
left circle) can view dashboards (defined in the role) on their team (the right circle).

You can grant a role to many different user groups which in turn have different target user groups. Thus, you can
easily achieve a high degree of granularity.

Example
You could have a "Regional HR Administrator" role and use permission groups to make sure that US Admins are
limited to managing employees in the United States, while Europe Admins are limited to managing employees in
Europe, or AsiaPac Admins are limited to managing employees in AsiaPac. You would have only a single role
called "Regional HR Administrator" and would use groups to control access. Your groups would be "AsiaPac
Admins", "US Admins", "Europe Admins", "AsiaPac Employees", "US Employees", and "Europe Employees".

Implementing Role-Based Permissions

Introduction CONFIDENTIAL 9
The role-based permission framework allows as many roles in the system as a company requires. At the same time,
each role can have a different level of permission granularity.

Implementing Role-Based Permissions

10 CONFIDENTIAL Introduction
2 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 13]

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 14]

Determine who needs permission to manage RBP and grant Granting Permissions to Manage RBP [page 15]

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 16]

Design the RBP configuration: Design the RBP Configuration [page 17]

● 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 32]
duction instance are in sync Configuring Fields for Setting up Permission Groups [page 32]
● Configure the fields that need to be available for selecting
group members

Create groups in the test instance. How do you create a permission group? [page 35]

Create roles and grant roles to groups on the test instance. How do you create a permission role? [page 41]

Conduct tests to check if groups and roles have been set up Conducting tests [page 53]
correctly

Implementing Role-Based Permissions

Implementation Sequence CONFIDENTIAL 11
 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 Copying RBP Configuration to Production Instance [page 66]
production instance

Implementing Role-Based Permissions

12 CONFIDENTIAL Implementation Sequence
3 Initial Setup Tasks

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

Implementing Role-Based Permissions

Initial Setup Tasks CONFIDENTIAL 13
3.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.

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

Implementing Role-Based Permissions

14 CONFIDENTIAL Initial Setup Tasks
● Wait 24 hours, and the system will automatically refresh.

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

Implementing Role-Based Permissions

Initial Setup Tasks CONFIDENTIAL 15
Related Information

Creating a Super Administrator [page 13]

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

Granting Permission Roles [page 45]

Creating Permission Roles [page 41]

Implementing Role-Based Permissions

16 CONFIDENTIAL Initial Setup Tasks
4 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 18] 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 18] in the non-RBP instance.
2. Go through the RBP module coverage [page 18] section and evaluate the impact for your RBP
implementation.
3. Familiarize yourself with the recommendations and best practices [page 27].
4. See the basic roles [page 29] 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
45], especially how you can use relationships [page 47].
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.

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 17
4.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.

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

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

Implementing Role-Based Permissions

18 CONFIDENTIAL Designing the RBP Configuration
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.

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 19
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

Implementing Role-Based Permissions

20 CONFIDENTIAL Designing the RBP Configuration
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.

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 21
Module Is it covered in RBP? Controlled by RBP Not controlled by RBP

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

Implementing Role-Based Permissions

22 CONFIDENTIAL Designing the RBP Configuration
 Module Is it covered in RBP? Controlled by RBP Not controlled by RBP

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
2.0 to other Users
● Access to Execution Map population of the "Access to
under Goal Execution Goal 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 Con­
figuration of Goal Execu­
tion

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 23
Module Is it covered in RBP? Controlled by RBP Not controlled by RBP

Home Page ● Everyone sees the home

page
● Items visible on the
Home Page are based on
user’s permissions to
those individual 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

Implementing Role-Based Permissions

24 CONFIDENTIAL Designing the RBP Configuration
 Module Is it covered in RBP? Controlled by RBP Not controlled by RBP

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

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 25
Module Is it covered in RBP? Controlled by RBP Not controlled by RBP

Reports Menu – Dashboards Controlled by RBP: Cell and field level permis­
& Analytics sions are not adhered to in ad
● Access to specific dash­ hoc reports or dashboards,
boards and reports under except for Employee Profile
Analytics (opt-in).
● 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 sepa­
Reports” permission in RBP.
rate RBP permission page
within WFA app and does not
link through to BizX RBP.

Implementing Role-Based Permissions

26 CONFIDENTIAL Designing the RBP Configuration
 Module Is it covered in RBP? Controlled by RBP Not controlled by 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
● Ability to view users on
matrix grid reports
● Ability to view users on
succession org chart and
lineage chart

4.4 Recommendations and Best Practices

4.4.1 General

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

● Start with most generic roles

Implementing Role-Based Permissions

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

Implementing Role-Based Permissions

28 CONFIDENTIAL Designing the RBP Configuration
4.4.2 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.

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

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 29
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
either.

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

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

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

Implementing Role-Based Permissions

30 CONFIDENTIAL Designing the RBP Configuration
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.

Implementing Role-Based Permissions

Designing the RBP Configuration CONFIDENTIAL 31
5 Preparing the Instance

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

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

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

Implementing Role-Based Permissions

32 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

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

Implementing Role-Based Permissions

Preparing the Instance CONFIDENTIAL 33
 <standard-element-ref refid="custom06"/>
<standard-element-ref refid="custom01"/>
</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.

Implementing Role-Based Permissions

34 CONFIDENTIAL Preparing the Instance
6 Setting up Groups and Roles

6.1 Creating Permission Groups

Use this topic to understand how to create permission groups.

Context

Permission groups contain groups of users who require a similar set of permission roles. These employees can be
grouped based on the types of tasks they need to perform. Additionally, you can create static or dynamic groups.
Dynamic groups are created based on employee attributes whereas Static groups are created by adding each user
to a group by user name.

Procedure

Go to the Admin Center Tools and search for Manage Permission Groups.

Use this screen to:

○ Create New Permission Groups (Dynamic)
○ Import Static Groups
○ Create Static Group For Learning Roles

These screens contain the Take Action dropdown menu to manage and modify permission groups in the following
ways:

○ Edit
○ Copy
○ Delete
○ View summary
○ View change history

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 35
6.1.1 Dynamic Permission Groups

Dynamic Permission groups are created automatically when the attributes of employees match the group selection
criteria.

Context

This section describes how Administrators create and manage Dynamic Permission Groups for both Employees
and External Users.

Procedure

1. Click the Create New button to create a new Permission Group.

The Permission Group page opens.

2. In the Group Name field, enter a name for your Permission Group.
3. Click on the User Type dropdown menu, and choose a user type.

The available User Types vary depending on how your system is configured. Possible values may include:
○ Employee (default)
○ External Learning User

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.

Note
When defining External Learning User groups, it is recommended that you do not create more than 50
groups.

4. In the Choose Group Members section, click the Pick a Category dropdown menu and select a category to
identify employees who fit your People Pool search criteria.
5. In the Search Results screen, enter a search term or click the magnifying glass, 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.
6. Make your selection and click Done.
7. 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.

Implementing Role-Based Permissions

36 CONFIDENTIAL Setting up Groups and Roles
 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.

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

9. 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.
10. If you want to prevent the group being updated automatically when new employees match the selection
criteria, click Lock group.
11. Click Done to complete the process.

6.1.2 Static Permission Groups

Static permission groups are created by adding individual user names to a group.

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

Currently you can do the following with static permission groups:

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

● Import static permission groups via CSV file. You can do a full or replacement import.

Viewing Members of a Static Permission Group

To view members of a static group, in the Admin Center go to Set User Permissions Manage Permission
Groups .

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 37
1. Locate the static group in the column Static or Dynamic.
2. Click the group name or click Take Action View summary to view details of a permission group.

Adding Members to a Static Permission Group

To add members to a static group, in the Manage Permission Groups screen, locate the static group in the Group
Name column.

1. Click the name of the static group. The Permission Group screen appears and contains the Add User and Delete
user buttons.
2. To add a user to a static group, click the Add User button. The Search Results screen appears.
3. In the Search and Select Items screen, enter the user name (or keywords) in the search box and click the
magnifying glass to display a list of user names.
4. To select names to be added, place a checkmark in the checkbox or use the Select All button to add all the
names in the Search Results list. As you choose user names to be added, the selected name appears in the
Selected Items section of this screen.
5. Use the Select None button, Remove All button, or the Delete icon to edit the list of users to be added.
6. To add the user, click Done.

Deleting Members from a Static Permission Group

To delete members of a static group, in the Manage Permission Groups screen, locate the static group in the Group
Name column.

1. Click the name of the static group. The Permission Group screen appears and contains the Add User and Delete
user buttons.
2. To delete a user from a static group, place a checkmark in the checkbox next to the user name to be deleted.
3. Click the Delete button. The user is deleted.
4. Click Close.

Implementing Role-Based Permissions

38 CONFIDENTIAL Setting up Groups and Roles
Creating or Modifying a Static Permission Group

Full Replacement Import

In the Admin Center go to Set User Permissions Manage Permission Groups

1. Click the Import Static Groups button to create or modify static groups by uploading a static group data file.
2. From the popup window, Select Full Replace and then download a blank CSV template to see the file format.
The template has two column headers: GROUPNAME and USERID.

3. Add the static group name in GROUPNAME column and user IDs of users that belong to the static group to the
USERID column. Please note the character encoding of the 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.

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 39
4. After importing complete, you will receive an email notification with success or error messages. A successfully
created group is then displayed in the group list upon refreshing.

5. Select the file with the data by clicking the Choose File button. Select Full Replace. Click the Validate File button
to validate file format, file size, etc. If the validation is successful, click Upload to import the static permission
groups. The import process will be run as a background job. Please note that for one group type, a maximum of
two jobs can run at the same time.

Delta Replacement Import

In the Admin Center go to Set User Permissions Manage Permission Groups

1. Click the Import Static Groups button to create or modify static groups by uploading a static group data file.

Implementing Role-Based Permissions

40 CONFIDENTIAL Setting up Groups and Roles
2. From the popup window, click Delta Replace and then download a blank CSV template to see the file format.
The template has two column headers: GROUPNAME and USERID.

3. Add the static group name in GROUPNAME column and user IDs of users that belong to the static group to the
USERID column. Please note the character encoding of the 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 Service to modify the system configuration file.
4. Select the file with the data by clicking the Choose File button. Select the Delta Replace. Click the Validate File
button to validate file format, file size, etc. If the validation is successful, click the Upload button to import the
static permission groups. The import process will be run as a background job. Please note that for one group
type a maximum of two jobs can be pending or running.
5. After importing has completed, you will receive an email notification with success or error messages. A
successfully created group is then displayed in the group list upon refreshing.

6.2 Creating Permission Roles

Permission roles can be created for employees and for external users, such as External Learning Users.

Context

Permission roles contain a group of permissions that can be granted 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.

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 41
Procedure

1. Go to the Admin Center.

2. In the Tools Search field, select Manage Permission Roles.
3. To add a Permission Role, click the Create New button. The Permission Role Detail page opens.
4. In the Role Name field, type a name describing of what the role allows you to do.
5. In the Description field, provide a statement describing what the role allows an employee to do. Add a note
about when the role was created and by whom.
6. 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.
7. 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.

8. Select the checkboxes next to the permissions you'd like to grant to the role.
9. Click the Done button when you finish marking your selections.
10. In the Grant this role to section, click the Add button to select the employees to be granted this permission.
11. Grant the permissions and specify the target population according to what you have defined in the workbook.
For a detailed description, see the section Granting Permission Roles [page 45]
12. 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 him/herself.

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.

13. Click the Done button to assign this role to the defined users. You are taken back to the Permission Role Detail
page.

Implementing Role-Based Permissions

42 CONFIDENTIAL Setting up Groups and Roles
14. Click the Save Changes button to complete creating the role.

Next Steps

Once this role is successfully created, the new role will be listed on the Permission Role List page.

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

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

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

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 43
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.

13. Click Save Changes.

6.2.2 Configuring a JAM Private Role to enable full search in

Mobile

To configure a JAM private role to enable full search in mobile, configure an RBP role with “User Search”
permission, and grant to the appropriate access group and target population.

The system creates a default user search role if a company is RBP enabled when this feature is first rolled out to
maintain backward compatibility for user search.

Implementing Role-Based Permissions

44 CONFIDENTIAL Setting up Groups and Roles
6.3 Granting Permission Roles

You can grant a permission role to everyone or to a subset of employees, determined by permission groups, target
population, or relationships.

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

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:

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 45
 ○ select Everyone (External Learner)
○ select Target population of: and check the checkbox to Select... to define the group

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.

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.

● 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 47].

Implementing Role-Based Permissions

46 CONFIDENTIAL Setting up Groups and Roles
6.3.1 Using Relationships to Grant Permissions

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

General Relationship Types

The five relationships are:

● Manager
● Second/Alternate Manager
● HR Manager
● Matrix Manager
● Custom Manager

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: Relationship Types for Global Assignments

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:

● Home Managers
● Home HR Managers
● Host Managers
● Host HR Managers

6.3.2 Specifying the Hierarchy Depth

Understand how to use hiearchy depth when granting 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.

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 47
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:

Implementing Role-Based Permissions

48 CONFIDENTIAL Setting up Groups and Roles
6.4 Granting Permissions for MDF Objects

You can grant permissions for viewing or editing generic objects which are part of the Meta Data Framework (MDF).
These objects, such as Position, Time, or Absence, appear under Miscellaneous Permissions when you create
permission roles.

Whenever you select to add permissions for a generic object to a permission role, you have to define a target
population for this object. For this, the Specify the target population for the other objects section appears on the
Grant this role to… screen. The target population in this context is made up of the specific objects that may be
accessed. When you grant the role to the permissioned users, you use various selection criteria to specify the
specific objects.

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 49
 Example
You grant the permission to edit positions. As target population for this permission, you define the finance
department. The permissioned users are then allowed to change positions in the finance department only. If you
would choose All , the users could change all positions.

6.5 View, Edit and Copy Permission Groups

You can edit, copy, or delete permission groups, view a summary of a permission group, and view its change
history.

Context

Note
You can only delete a permission group if it has no associated role.

Implementing Role-Based Permissions

50 CONFIDENTIAL Setting up Groups and Roles
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.

6.6 View, Edit and Copy 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.

Implementing Role-Based Permissions

Setting up Groups and Roles CONFIDENTIAL 51
 Implementing Role-Based Permissions
52 CONFIDENTIAL Setting up Groups and Roles
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.

Implementing Role-Based 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.

Implementing Role-Based Permissions

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

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

56 CONFIDENTIAL RBP Ad Hoc Reports
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.

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

58 CONFIDENTIAL RBP Ad Hoc Reports
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.

Implementing Role-Based 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.

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

Troubleshooting CONFIDENTIAL 61
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.

1. Go to Administration Tools.
2. In the Manage Employees portlet, select Set User Permissions.
3. In the Set User Permissions section, select User Role Search.

Implementing Role-Based Permissions

62 CONFIDENTIAL Troubleshooting
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.

Implementing Role-Based Permissions

Troubleshooting CONFIDENTIAL 63
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.

1. Go to Administration Tools.
2. In the Manage Employees portlet, select Set User 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

Implementing Role-Based Permissions

64 CONFIDENTIAL Troubleshooting
 Reports" and "vstokes" is a direct report of "cgrant".

Implementing Role-Based Permissions

Troubleshooting CONFIDENTIAL 65
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.

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

68 CONFIDENTIAL Copying RBP Configuration to Production 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.

Implementing Role-Based Permissions

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.

Implementing Role-Based Permissions

70 CONFIDENTIAL Copying RBP Configuration to Production Instance
11 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 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.

Implementing Role-Based Permissions

Running the RBP Diagnosis Tool CONFIDENTIAL 71
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.

Implementing Role-Based Permissions

72 CONFIDENTIAL Important Disclaimers and Legal Information
Implementing Role-Based Permissions
Important Disclaimers and Legal Information CONFIDENTIAL 73
go.sap.com/registration/
contact.html

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