ADMINISTRATION GUIDE | CONFIDENTIAL

SAP SuccessFactors Foundation

Document Version: Q4 2018 – 2018-11-30

Migrating to Role-Based Permissions

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

THE BEST RUN

Content

1 What's New in The RBP Migration Guide. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Introduction to Role-Based Permissions Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .6

2.1 Choose an RBP Migration Strategy. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3 Getting Started with Role-Based Permissions Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.1 Assess Your Security Model Complexity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Prerequisites to RBP Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3 Recommendations for RBP Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4 Engage with an Implementation Partner. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4 Preparing for RBP Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.1 Steps to Prepare for RBP Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Reviewing Existing Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Completing Role-Based Permissions Training. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Gathering Requirements Using Best Practices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Documenting the Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Creating a Project Plan. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Creating Test Scripts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Migrating to RBP Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.2 Prepare Your Instance for Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Assess Your Instance Types. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Creating Incidents for RBP Migration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Requesting an Instance Refresh. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3 Enable Role-Based Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Prerequisites to Enabling RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Enabling RBP in the Admin Center. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .35
Granting Administrators Access to RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Granting Permission to Platform Feature Settings. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Disable RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

5 Migrating to RBP Using the Migration Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

5.1 Is This Tool Recommended for Me?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 How to Use the RBP Migration Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Defining Roles in the RBP Migration Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Assigning Permissions to a Role in the RBP Migration Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Granting Rules to Roles in the Migration Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Review and Publish. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

Migrating to Role-Based Permissions

2 CONFIDENTIAL Content
6 Migrating to RBP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.1 What are Role-Based Permissions?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Permission Role Assignments. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

7 Testing Your Role-Based Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .75

7.1 RBP Ad Hoc Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Enabling Ad Hoc Reports with Cloud Support. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Granting Permissions to Reports. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Creating a Permissions Report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Setting Up a Report with Permission Filters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
7.2 Testing Your RBP Configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Using the Check Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Does the Everyone Group Exist?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Do Roles Exist Without Groups or Users?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Do Roles Exist Without Target Population?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Do Group Names Exceed 1000 Characters?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
Do Target Group Names Exceed 1000 Characters?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Does a User Have the Same Permission More Than 30 Times? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Does a Role Have More Than 100 Rules?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

8 Copying Configuration to the Production Instance. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87

8.1 Important Tips for Copying Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
8.2 Important Tips for Copying Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

9 Role-Based Permissions Configuration Workbook. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

10 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.1 How can you check the permissions assigned to a user?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
10.2 How can you run an ad hoc report?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .92
10.3 How do you run a user search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
10.4 Running the RBP Diagnosis Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .96

Migrating to Role-Based Permissions

Content CONFIDENTIAL 3
1 What's New in The RBP Migration Guide

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

Q4 2018

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

What's New Description More Info

We've added Migration Tool Document. The migration tool can be used to start Choose an RBP Migration Strategy [page
the process of RBP migration. The sec­ 7]Migrating to RBP Using the Migra­
tion that has been added is called "Mi­ tion Tool [page 39]
grating to RBP Using the Migration Tool".

Q3 2018

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

What's New Description More Info

We've updated the topics in this guide for We've added Configuration Check Tool Each check tool for RBP is described in
the topic "RBP Configuration Checks".
accuracy. information to the "Testing RBP" section.

Under "Migrating to RBP", we've added

"What are Role-Based Permissions? As
well as its subsequent topics.

Q2 2018

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

What's New Description More Info

In the section Preparing for Migration The steps to prepare have been broken
and topic Steps to Prepare for Migration into tables that indicate when you, the
we've streamlined the content. customer, must provide information and
the tasks that will be done on your behalf
by customer support.

Migrating to Role-Based Permissions

4 CONFIDENTIAL What's New in The RBP Migration Guide
What's New Description More Info

Enable RBP in the Admin Center Enabling RBP can now also be done in
the Admin Center with Super Admin cre­
dentials. We've added procedures and
prerequisites on how to do this.

Q1 2018

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

What's New Description More Info

Restructured the guide to streamline the This guide now contains sections for
RBP migration guidance. each stage of the RBP migration. The in­
structions in this guide have also been
updated with additional information.

Q4 2017

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

What's New Description More Info

Initial publication of this guide to custom­ This migration guide is now available for
ers. customers. Configuring certain aspects
of Role-Based Permissions is still largely
done through Provisioning, which, as a
customer, you cannot access. Please
contact SAP Cloud Support (CS) to com­
plete any tasks in Provisioning.

Migrating to Role-Based Permissions

What's New in The RBP Migration Guide CONFIDENTIAL 5
2 Introduction to Role-Based Permissions
Migration

Role-Based Permissions (RBP) control access to the SAP SuccessFactors application and controls what users can
see and edit. RBP is a suite wide-authorization concept, which applies to most modules. Use this topic to
understand RBP migration and for things to consider during the migration process.

This guide provides instructions and recommendations for any customer still using the legacy security permissions
model, or non-RBP customers, who are required to migrate to Role-Based Permissions (RBP). We encourage you to
use the RBP Migration Tool to perform your migration but if you feel you need assistance to complete the migration
process, you can engage with an Implementation Partner. To learn more about how to engage with an
Implementation Partner, go to the link below: Choosing an Implementation Consultant

You can use this guide to determine the complexity of your migration, based on your product implementation, and
you can use this guide to plan your migration strategy. Use the following topic to analyze the complexity of your
RBP product migration: Assess Your Security Model Complexity

 Note

RBP migration is not an automated process. It requires downtime, so plan accordingly. This document focuses
on migrating your existing permissions only.

Related Information

Choose an RBP Migration Strategy [page 7]

Choosing an Implementation Consultant
Assess Your Security Model Complexity [page 9]
Migrating to RBP Using the Migration Tool [page 39]

Migrating to Role-Based Permissions

6 CONFIDENTIAL Introduction to Role-Based Permissions Migration
2.1 Choose an RBP Migration Strategy

You can migrate to role-based permissions using the migration tool, manually without the migration tool, or using
an implementation partner. Choose a strategy based on the needs of your system.

Migrate with an Implementation Con­

Migration Tool (Self Migration) Manual Migration (Self Migration) sultant

When you choose to migrate using the When you manually migrate, meaning, If you would like to engage with an imple­
RBP migration tool, you'll have access to you choose to migrate without the use of mentation consultant use the following
predefined role templates. These role the migration tool, you can manually cre­ document to learn how to engage with a
templates may include default access ate the necessary groups and roles consultant: Engage with an Implementa­
groups, default target groups and some needed for your system and assign role- tion Partner [page 16]
default role-based permissions. based permissions. For information
about how to manually migrate to RBP,
From the migration tool you'll have the
use the following document: What are
ability to create and assign groups to the
Role-Based Permissions? [page 54]
predefined roles in the tool and to map
some of your legacy permissions to RBP.
 Note
For information about how to use the
Ensure that you read prerequisites
RBP Migration Tool, use the following
document: Migrating to RBP Using the and recommendations prior to be­
Migration Tool [page 39] ginning your RBP migration process.

 Note
The migration tool will help you get
started with your migration by help­
ing you to map some of your legacy
permission to RBP. You can also use
the tool to add any additional RBP to
your roles directly from the tool.

 Note
Ensure that you read prerequisites
and recommendations prior to be­
ginning your RBP migration process.

Related Information

Prerequisites to RBP Migration [page 15]

Recommendations for RBP Migration [page 15]

Migrating to Role-Based Permissions

Introduction to Role-Based Permissions Migration CONFIDENTIAL 7
3 Getting Started with Role-Based
Permissions Migration

Review each topic in this section carefully to ensure that you understand the prerequisites and recommendations,
and to assess whether or not you need an implementation partner.

Role-Based Permissions Migration Workflow

This overview provides a quick glimpse of the RBP migration processes. Read through each description and
complete the tasks within each phase to complete your migration. This image is interactive. You can hover over
each section for a description of its phase and click the image to go directly to that section in this document.

● Getting Started with Role-Based Permissions Migration [page 8]

● Preparing for RBP Migration [page 17]
● Migrating to RBP [page 54]
● Testing Your Role-Based Permissions [page 75]

Assess Your Security Model Complexity [page 9]

To help you evaluate your migration process, each product security model can be categorized as simple or
complex. Use this section to evaluate your product migration complexity.

Prerequisites to RBP Migration [page 15]

Review and perform each prerequisite on this page before starting the RBP migration process.

Recommendations for RBP Migration [page 15]

Observe the recommendations in this topic for tasks that you may want to perform before starting your
migration.

Engage with an Implementation Partner [page 16]

Here, you'll find information about how to find an implementation partner.

Migrating to Role-Based Permissions

8 CONFIDENTIAL Getting Started with Role-Based Permissions Migration
Related Information

Choosing an Implementation Consultant

Migrating to Role-Based Permissions Community Blog

3.1 Assess Your Security Model Complexity

To help you evaluate your migration process, each product security model can be categorized as simple or
complex. Use this section to evaluate your product migration complexity.

Role-Based Permissions migration is required for all customers that do not currently have the RBP security model
implemented and is required for all customers who wish to use the SAP SuccessFactors Data Protection and
Privacy features, such as Data Purge and Data Subject Information Report.

The security model tables below provide guidance on how to determine if your security model is considered simple
or complex. If your security model is described as Simple, you should be able to complete your RBP migration on
your own, using the migration tool. If your security model is described as Complex, you may still have the ability to
compete the migration on your own, using the migration tool. However, you can engage with your Implementation
Partner if you feel the migration is to complex.

Please use the following questions to help you to determine if your security model is simple or complex. If you
answer Yes to any of the following four questions, for the products listed in the tables below, then your security
model is considered complex.

● Do you require assistance to understand how to create groups and map them to roles?
● Do your roles require multiple levels of depth in the relationship hierarchy?
● Do you need to create a specific role for the one or more role types that have different permissions?
● Do you need assistance configuring custom dynamic group filters?

This table contains a snapshot of each product and its security model assessment. Scroll further to find your products and the
details about the product's security model. *Asterisks in the table indicate that the product can be considered Simple or
Complex.

Complex Security Model

Simple Security Model
(Customer / Implementation Partner performs the RBP mi­
(Customer performs the RBP migration) gration)

*Analytics *Analytics

Calibration Compensation / Variable Pay

Career Development Plan Custom Reports

*Employee Profile *Employee Profile

Goal Management Recruiting

Learning Succession (role / legacy-position)

Migrating to Role-Based Permissions

Getting Started with Role-Based Permissions Migration CONFIDENTIAL 9
 Complex Security Model
Simple Security Model
(Customer / Implementation Partner performs the RBP mi­
(Customer performs the RBP migration) gration)

Mobile *Workforce Analytics

Performance Management

Platform

Presentations

*Workforce Analytics

Security Model Assessment Details:

Analytics

Complex Security Model

Simple Security Model
(Implementation Partner engagement is recommended for
(Customer performs the RBP migration.) RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

Tiles/Dashboard, Standard Reports and Online Report De­ Tiles/Dashboard, Standard Reports and Online Report De­
signer (ORD) signer (ORD)

● Access to specific dashboards and reports. Your security model is complex if:
● Access to target populations the user will be able to report
● you have target population/group settings, which will im­
on.
pact dataset availability within Ad Hoc Reporting and On­
● Reporting is done within HR with little to no self-servicing line Report Designer. (For example, the Succession MDF
reporting access to other groups outside of HR. (For ex­ Position reporting schema is used and has specific target
ample, managers or employees). population/group criteria.)
● you have target population/group settings which will im­
pact dataset availability within Advanced Reporting.

Calibration

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Calibration tab.

● Access to employees who the users will see within Calibration.

Migrating to Role-Based Permissions

10 CONFIDENTIAL Getting Started with Role-Based Permissions Migration
Career Development Plan

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Career Development Plan (CDP) Access Permission

● Career Worksheet Access Permission
● Recommended Successors

Compensation / Variable Pay

Complex Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Compensation Menu

● Access to Executive Reviewer

Considerations to keep in mind when preparing to migrate to RBP:

● Executive Review Permissions should be set based on organization.

● Compensation Statements (e.g., Combined Statement, Variable Pay Statement) add additional complexity when consider­
ing the migration to RBP.

 Note
If the data model does not have specific XML code for standard elements an engagement will be required.

● Variable Pay Individual Review must remain as legacy permission in the data model or the VRP view will not be accessible.

Custom Reports

Complex Security Model

(Implementation Partner engagement is recommended for RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

Custom Reports

Your security model is complex if you have had any custom reports created. Please identify these custom reports prior to the
migration. These reports are not compatible with Role-Based Permissions and will need to be re-created.

 Note
We recommend that you engage with an Implementation Partner.

Migrating to Role-Based Permissions

Getting Started with Role-Based Permissions Migration CONFIDENTIAL 11
Employee Profile

Complex Security Model

Simple Security Model
(Implementation Partner engagement is recommended for
(Customer performs the RBP migration.) RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Employee Profile. Your security model is complex if:

● Field Level permissions to employee data.
● you use both predefined and custom roles.
● Use predefined fields.
● these roles require different permissions and tie to custom
roles with granularity that would be defined using filters.

Goal Management

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Goal tab.

● Access to Goal plan(s) and admin permissions.
● Access to allow the role to create a Group Goal (Group Goal 2.0).
● Access to allow the role to assign a Group Goal (Group Goal 2.0) to other Users.
● Access to Import Goals.
● Access to Import / Export Goals library.

Learning

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Learning Menu.

● Access to Learning User Permissions.
● Access to Learning Administration.

Mobile

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Mobile Access
● Access to Enable Mobile Features
● Manage Mobile Users
● Enable User Search for All Employees

Migrating to Role-Based Permissions

12 CONFIDENTIAL Getting Started with Role-Based Permissions Migration
Performance Management (PMv12A / 360)

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Performance tab.

● Access to Create forms.

Platform/Foundation

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Admin Center

Presentations

Simple Security Model

(Customer performs the RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● Access to Presentations tab.

● Access to specified users or roles.
● Access to Manage Talent Card (and view employee data).

Recruiting Management

Complex Security Model

(Implementation Partner engagement is recommended for RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

● All features under Recruiting Permissions in Permission settings.

● Administrator permissions
● Permission to create forms and the report permissions are shared with other modules

Succession (role / legacy-position)

Complex Security Model

(Implementation Partner engagement is recommended for RBP migration.)

The bulleted lists below specify which features you will have access to after RBP is configured.

Migrating to Role-Based Permissions

Getting Started with Role-Based Permissions Migration CONFIDENTIAL 13
Complex Security Model

(Implementation Partner engagement is recommended for RBP migration.)

● Access to Succession tab.

● Access to User and Administrator permissions.
● Controls target population and which users and details can be viewed by the logged in user.

Workforce Analytics

Complex Security Model

Simple Security Model
(Implementation Partner engagement is recommended for
(Customer performs the RBP migration.) RBP migration.)

Workforce Analytics is made available only to employees who Your security model is complex if:
have data access to all organizational units.
● you have made Workforce Analytics available to HR Busi­
ness Partners that only have access to the business area
they manage.
● you have had any custom reports created. Please identify
them prior to the migration. These reports are not com­
patible with Role-Based Permissions and will need to be
re-created.

 Note
We recommend that you engage with an Implementa­
tion Partner.

Related Information

Migrating to RBP Using the Migration Tool [page 39]

Migrating to Role-Based Permissions

14 CONFIDENTIAL Getting Started with Role-Based Permissions Migration
3.2 Prerequisites to RBP Migration

Review and perform each prerequisite on this page before starting the RBP migration process.

Prerequisites

The following is a list of prerequisites that must be met before migrating to Role-Based Permissions (RBP). Review
this list carefully:

● For customers who wish to migrate to Role-Based Permissions (RBP), it is essential that you fully understand
how Role-Based Permissions work. For this reason, it is necessary that you take the Role-Based Permissions
training. You can access this course through the SAP Learning Hub, the course is called SAP SuccessFactors
Foundations Administration - HR800e (e-Learning). Within this course, Unit 6 contains specific information
dedicated to RBP training. Please see the SAP SuccessFactors HCM Global Training webpage for more
information. That webpage is linked in the Related Information section below.
For login instructions, please review the SuccessFactors Admin Learning Center (SFALC) guide: SFALC
Access Guide
● Review the Assess Your Security Model Complexity section, in this guide, to determine if an implementation
partner is recommended or if you can migrate to RBP without this engagement.
● You must enable role-based permissions. You can enable role-based permissions in your system by following
the instructions in the topic Enable Role-Based Permissions.

Related Information

Enable Role-Based Permissions [page 34]

SAP SuccessFactors Training (RBP Training - Unit 6)

3.3 Recommendations for RBP Migration

Observe the recommendations in this topic for tasks that you may want to perform before starting your migration.

Recommendations

● Allow enough time and resources to complete and test the migration (on your own or with an Implementation
Partner) as well as ample time to complete the project in both your non-productive (e.g., sandbox,
development, test, preview) and productive instances. Check out the Related Information section below learn
how to find an implementation partner.

Migrating to Role-Based Permissions

Getting Started with Role-Based Permissions Migration CONFIDENTIAL 15
● We recommend that an Instance Refresh is completed before beginning the RBP migration project. This helps
to ensure that testing is consistent post-RBP implementation. An Instance Refresh can take from 2-4 weeks, so
please allow enough time. See the knowledge base article in the Related Information section below to find out
how to request an instance refresh.
● The migration procedures in this guide are written for customers that have a simple security model only. See
the Assess Your Security Model Complexitysection, in this guide, to understand the differences between a
Simple model and Complex model. If your security model is Complex, we recommend that you contact an
Implementation Partner.
● Create a RBP Migration Request by logging in to the SAP ONE Support Launchpad linked below. Also linked,
are instructions about how to create these requests. For those instructions see, Creating Incidents for RBP
Migration

 Note

RBP migration is not an automated process. It will require downtime, so you'll need to plan accordingly. It's
required that you create a RBP Migration Request for both non-productive (e.g., sandbox, development,
test, preview) and productive instances, when migrating without an Implementation Partner. When
requesting to have Role-Based Permissions enabled in the production instance, the Instance Sync will not
be automatically requested. However, you can request that Instance Sync is enabled when you request to
have RBP enabled.

An incident will be required for SAP Cloud Support (CS) to enable RBP. For more information about how to
create a support incident, please see the Knowledge Base Article (KBA) in the Related Links section below.
● Listen to the prerecorded webinar for Role-Based Permission Migration linked below.

Related Information

Engage with an Implementation Partner [page 16]

Knowledge Base Article: How to Create a New Instance, a Test Instance, an Instance Refresh, or a Clone
Creating Incidents for RBP Migration [page 28]
Migration to Role-Based Permissions Webinar

3.4 Engage with an Implementation Partner

Here, you'll find information about how to find an implementation partner.

If an Implementation Partner engagement is recommended, please contact your SAP SuccessFactors Account
Representative to provide you guidance on next steps.

For more information about Implementation Partner (SAP/Partner) engagements, see this page in the SAP
SuccessFactors Community. Choosing an Implementation Consultant

Migrating to Role-Based Permissions

16 CONFIDENTIAL Getting Started with Role-Based Permissions Migration
4 Preparing for RBP Migration

Before migrating to role-based permissions, complete the tasks outlined in these topics, such as reviewing your
existing permissions, gathering and documenting permission requirements, and creating support tickets to begin
your migration. When defining the configuration, consider the best practices regarding maintenance and
performance.

Steps to Prepare for Migration

Complete the preplanning steps defined this process map to begin your migration. When you've completed these
steps, begin the tasks outlined in Prepare Your Instance for Migration.

Hover over each step in the image for a description. Click on each phase for more information.

● Reviewing Existing Permissions [page 18]

● Completing Role-Based Permissions Training [page 22]
● Gathering Requirements Using Best Practices [page 23]
● Documenting the Requirements [page 24]
● Creating a Project Plan [page 25]
● Creating Test Scripts [page 25]
● Migrating to RBP Overview [page 26]
● Copying Configuration to the Production Instance [page 87]

Steps to Prepare for RBP Migration [page 18]

The steps to prepare for your migration should occur before you enable role-based permissions in your
system. These steps will help you to thoroughly understand your current security system permissions.

Prepare Your Instance for Migration [page 27]

Preparing your test and production enviornments for migration is an essential part of the process. Before
performing the tasks in this section, ensure that you've read through the topic Step to Prepare for RBP
Migration. This phase requires you to asess and understand your current enviornments and to create
refresh incidents with SAP SuccessFactors.

Enable Role-Based Permissions [page 34]

As a super admin, you can enable role-based permissions using the admin center. Use this section to learn
how to enable RBP and understand the pre-requisites to this performing task.

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 17
4.1 Steps to Prepare for RBP Migration

The steps to prepare for your migration should occur before you enable role-based permissions in your system.
These steps will help you to thoroughly understand your current security system permissions.

When preparing to migrate, your project should begin with a clearly defined plan. To begin defining your project
plan, start by reviewing the permissions that you have defined in your current security model, including the roles
that you need to create and the permissions that are needed for your user groups. In this phase of your migration,
it’s very important that you perform the following steps in order and as they are presented and consider best
practices regarding maintenance and performance.

4.1.1 Reviewing Existing Permissions

Reviewing your current permissions is critical to your RBP migration process. Use the task outlined in this topic to
understand your non-RBP instance.

Context

Each migration project team needs to understand the permissions that currently exist and document those
permissions. Identifying the roles and permissions from the old framework will provide the team with the
foundation to build out the plan to migrate to RBP. There are two ways to identify existing permissions. You can
identify existing permissions through comparison, as described in the second step or you can create a Security
Permissions Report, as described in the first step.

Procedure

1. Create a Security Permissions Report

Before you migrate an instance from the old permission framework to RBP, create a security permission report
to review your current permissions.
1. From the Admin Center, select Set User Permissions Security Permissions Report .
2. Check all reports listed and click Submit.
3. Once reports are completed, they are available for download in the following location: Admin Center
Reports Scheduled Reports
This report lists individual permissions.
4. Sort and filter the reports so that you're grouping the permissions that you want to set up as roles.
Similarly, sort and filter the reports so that you're grouping the employees that you want to set up as
groups.
5. Leveraging your existing groups, define each group. That is, define who should have access to whom.
6. Leveraging your existing roles, define each role. That is, define what data and functionality should be
accessed by who.

Migrating to Role-Based Permissions

18 CONFIDENTIAL Preparing for RBP Migration
 7. Assign the groups you've defined to the roles you've defined.
8. Create a tab in the RBP workbook to show how you've mapped the groups to the roles.
9. Add the roles and groups to the RBP workbook.
2. Identify Permissions on Existing Roles Through Comparison Check

Comparing your current permissions, as described in this step, can be done in addition to creating security
report. If necessary, you can perform both tasks to ensure that you've thoroughly gathered your permission
requirements. However, in cases where you don't have the option to create security reports, you can use this
task to assess your permission needs. Use the example below to understand how the comparison check can be
used.
1. Leveraging your existing groups, define groups, that is who should have access to whom.
2. Leveraging your existing roles, define roles, that is what data and functionality should be accessed by who.
As defined in your group definitions.
3. Create a tab in the RBP workbook to show how you've mapped the groups to the roles.
4. Add the roles and groups to the RBP workbook.

 Note

We suggest that you complete a comparison for each role by taking screenshots prior to enabling RBP. The
following are examples of legacy permission comparisons in Live Profile. You should view Profile, Scorecard
and History permissions on all the existing roles.

Example using comparison method in Employee Profile v12 / Live Profile

Example Image

 Note
The following displays are examples only and the im­
ages may appear differently in your system.
Example Description

Example view of permissions granted to a System Adminis­

trator viewing self in Profile

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 19
 Example Image

 Note
The following displays are examples only and the im­
ages may appear differently in your system.
Example Description

Example view of permissions granted to System Admin view­

ing self in Scorecard

Example of permissions granted to a Manager viewing self in

Profile

Example of permissions granted to a Manager viewing self in

Scorecard

Migrating to Role-Based Permissions

20 CONFIDENTIAL Preparing for RBP Migration
 Example Image

 Note
The following displays are examples only and the im­
ages may appear differently in your system.
Example Description

Example of permissions granted to a Manager viewing direct

reports in Profile

Manager, Brooke Brown, selected employee ELY EISLEY

Example of permissions granted to a Manger viewing direct

reports in Scorecard

Manager, Brooke Brown, selected employee ELY EISLEY

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 21
Related Information

Prerequisites to RBP Migration [page 15]

Running the RBP Diagnosis Tool [page 96]
Role-Based Permissions Configuration Workbook [page 90]
Creating Incidents for RBP Migration [page 28]

4.1.2 Completing Role-Based Permissions Training

It's important that you have a conceptual understanding of role-based permissions and how they control access to
the data in your solution. We recommend that you take the training described on this page.

Context

Complete the Role-Based Permissions training in Unit 6 of the Introduction to SAP SuccessFactors
Administration - HR800e (e-Learning) course. See the Prerequisites and Recommendations section in this
guide for more details. (See the Prerequisites and Recommendations linked in the Related Information section
below.)

 Note

Log into the SAP SuccessFactors Community and SAP Learning Hub to gain access to the course.

Procedure

1. Select the training link in the Related Information section to find the SAP SuccessFactors RBP training.
2. Select the Enter Here! link to the SuccessFactors Administrator Learning Center (SFLAC).
3. Select Foundations. Here, you'll find the HR800e (e-Learning) course.
4. Select the HR800e (e-Learning)link and go to Unit 6 - Role-Based Permissions.

Related Information

Prerequisites to RBP Migration [page 15]

Recommendations for RBP Migration [page 15]
SAP SuccessFactors Training (RBP Training - Unit 6)

Migrating to Role-Based Permissions

22 CONFIDENTIAL Preparing for RBP Migration
4.1.3 Gathering Requirements Using Best Practices

Review your current product permissions, they will help you to gather the requirements needed for SAP
SuccessFactors Role-Based Permissions migration.

Context

Work with the subject matter experts, within your company, for each of the SAP SuccessFactors products that you
have deployed. Determine the roles, the permissions those roles require, and who would be granted these roles.

Procedure

1. Starting with the five most basic roles, gather requirements using the following best practices and
recommendations:

Every company has a set of generic, basic roles, such as Manager or HR Manager. These roles tend to have
similar permissions. The list of the five basic (generic) roles includes their typical permissions. Use this list to
start the requirements discussion with your team. These roles do not require specific groups and some roles
might be split up into more specific roles. For example, your company does not have a single manager role, but
one manager role for each region because in each region they are allowed to see different data.

 Note

This document does not provide instructions for complex security models.

○ Administrator: allows access to administrative functionality

○ HR Role: allows HR access based on target group
○ Manager Role: allows access for managers to see and transact on their direct/indirect reports
○ Employee All: allows users to see data about everyone
○ Employee Self: allows the user to see their own data
2. Familiarize yourself with the following best practices:

○ Avoid redundancy
○ Do not allow overlap between roles
○ Limit the number of roles and groups
○ Use meaningful naming conventions
○ Define a governance that covers how changes to RBP will be handled in the future
○ 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. Note that you will need to create an incident ticket to have CS run this tool for you.
See the Diagnosis Tool section in this guide for more details. (See the Diagnosis Tool link in the Related
Links section below.)

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 23
4.1.4 Documenting the Requirements

Use the workbook to document the requirements you gathered in the previous step.

Context

After gathering requirements based on your current permission model, use your workbook to document those
requirements for your migration process.

Procedure

Document the requirements.

○ Create an RBP configuration workbook that lists the groups, roles, the 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, especially how you can use relationships. See the Role-Based Permissions Configuration
Workbook section in this guide for more details. (See the Role-Based Permissions Configuration Workbook link
in the Related Links section below.)
○ Remember to follow these steps when granting RBP in SAP SuccessFactors. Think of this process as who (the
permission group) can do what (permission role) to, or for whom (the target population).
○ Create Groups: Create a group and grant it the required permission, then create groups to be managed by
users with those permissions.
○ Create a Permission Role: Define the different roles. Permission roles define access to data and
application functionality.
○ Grant the Role to a User or Group: Link the target group (or population) created in the Create Groups
step with the roles created in the Create a Permission Role step. This is also referred to as “linking the role
to a target population.”

Related Information

Role-Based Permissions Configuration Workbook [page 90]

Migrating to Role-Based Permissions

24 CONFIDENTIAL Preparing for RBP Migration
4.1.5 Creating a Project Plan

Review the sections outlined in this topic to create your project plan.

Context

Create a project plan to keep track of your RBP migration process. Read through the following sections of this
document as you create your project plan:

Related Information

Steps to Prepare for RBP Migration [page 18]

Requesting an Instance Refresh [page 33]
RBP Ad Hoc Reports [page 75]
Troubleshooting [page 91]
Copying Configuration to the Production Instance [page 87]
Role-Based Permissions Configuration Workbook [page 90]

4.1.6 Creating Test Scripts

Creating your test scripts will help you to test your RBP configuration.

Context

Before copying your RBP configuration to production, you'll need to test your permissions, groups and roles.

Procedure

Create test scripts. You will test and validate against the requirements.

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 25
4.1.7 Migrating to RBP Overview

When you've completed the previous steps, you are ready to begin performing your migration.

Context

The list tasks below will help you understand which you are required to initiate.

Procedure

RBP Migration Steps

○ Instance Refresh (scheduling may take 2-4 weeks). See the Incident Creation Instructions section in this
guide for more details. (See the Incident Creation Instructions link in the Related Links section below.)
○ Customer is required to open an incident ticket.
○ SAP Cloud Support (CS) enables Role-Based Permissions in the non-productive instance. (This includes
Instance Sync).
○ Customer is required to open an incident ticket.
○ Customer configures Role-Based Permissions in the non-productive instance.
○ Customer performs validation in the non-productive instance.
○ SAP Cloud Support enables Role-Based Permissions in the productive instance.
○ Customer is required to open an incident ticket.
○ Customer copies the configuration from the non-productive instance to the productive instance using Instance
Sync.
○ Customer performs validation in the productive instance.
○ Cutover Execution: Customer verification. Role-Based Permissions Migration is complete.

Next Steps

When you've completed the tasks in the prerequisites and recommendations topics and the tasks outlined in Steps
to Prepare for RBP Migration, continue to the topic, Migrating to RBP.

Related Information

Migrating to RBP [page 54]

How to create a support incident

Migrating to Role-Based Permissions

26 CONFIDENTIAL Preparing for RBP Migration
4.2 Prepare Your Instance for Migration
Preparing your test and production enviornments for migration is an essential part of the process. Before
performing the tasks in this section, ensure that you've read through the topic Step to Prepare for RBP Migration.
This phase requires you to asess and understand your current enviornments and to create refresh incidents with
SAP SuccessFactors.

When you implement and configure Role-Based Permissions (RBP), this is performed first on a non-productive
instance (e.g., sandbox, development, test, or preview). Only after successful testing, should you copy the
configuration to the production instance. For this reason, it is very important that the non-productive instance and
the production instance contain the same data. This sections covers the following topics: Requesting an Instance
Refresh, AssessYour Instance Types, and Creating Incidents for RBP Migration.

Assess Your Instance Types [page 27]

Evaluate your instances and determine how your migration tasks will affect these instances.

Creating Incidents for RBP Migration [page 28]

Your RBP migration requires that you create incidences to initiate RBP Migration and to request an instance
refresh for your test and production environments.

Requesting an Instance Refresh [page 33]

Request the instance refresh in advance, scheduling can take up to four weeks.

4.2.1 Assess Your Instance Types

Evaluate your instances and determine how your migration tasks will affect these instances.

Assessing the differences between your sandbox, development, test, or preview instances is an import task in your
RBP migration process.

Remember, RBP is completely data dependent. When you migrate RBP, you'll need to first migrate your 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.

Prior to requesting the instance refresh, account for any differences in your non-productive (e.g., sandbox,
development, test, or preview) instances. The instance refresh overwritten, Account for these differences prior to
performing the instance refresh. For example, if you implement a new Performance Management form, you need to
first extract the XML and save it, because it will be overwritten and lost once the refresh is completed.

To make sure that test and production instance are in sync:

● Refresh the employee data file in the test instance with production data.
● Discuss internally, if there are data changes coming that would affect the ability to permission correctly (for
example organizational restructures). If so, the data must be available in the test instance if you want to add it
to your permissions 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.
● Are more features enabled in the production instance than in the test instance?
● Does the non-productive (e.g., sandbox, development, test, or preview) instance and production instance
contain differences that would affect the ability to set permissions correctly?
● Are there more features enabled in the productive (or production) instance than in the non-productive instance
or vice versa?

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 27
Depending on how much your instances are out of sync, you may have to export Employee User Data and push
configuration using Instance Synchronization from production into your non-productive instance. 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.

4.2.2 Creating Incidents for RBP Migration

Your RBP migration requires that you create incidences to initiate RBP Migration and to request an instance refresh
for your test and production environments.

Context

During the RBP migration project, you will need to open three incidents:

● The first incident is to request an Instance Refresh.

● The second is to enable Role-Based Permissions and to request an Instance Synchronization in your non-
production instance. It's important to note that this incident request is for the non-production instance only,
and it will include Instance Sync.
● The third incident is to enable Role-Based Permissions in the productive instance prior to copying
configuration to your production instance. This new incident request is for the productive instance, and it will
not include Instance Sync.

Procedure

1. From the SAP ONE Support Launchpad, enter an incident with the title: RBP Migration Request

Choose the appropriate incident description that you'll use to create the necessary incidents for your
migration. If you are migrating for reasons related to Data Privacy and Protection, choose a description from
the table that contains the keyword GDPR. If you are migrating for reasons unrelated to Data Privacy, choose a
description does not contain GDPR.

The incident is required so that SAP Cloud Support (CS) can enable RBP the initial setup.

Incident Descriptions for NON- Data Privacy and Protec­ Incident Descriptions for Data Privacy and Protection Mi­
tion Migrations gration (GDPR)

RBP Migration: RBP Migration Request for Super Admin

Creation

RBP Migration: RBP Migration Tool Issue

RBP Migration: Self-Enablement RBP Migration for GDPR: Self-Enablement

Migrating to Role-Based Permissions

28 CONFIDENTIAL Preparing for RBP Migration
 Incident Descriptions for NON- Data Privacy and Protec­ Incident Descriptions for Data Privacy and Protection Mi­
tion Migrations gration (GDPR)

RBP Migration: Instance Refresh RBP Migration for GDPR: Instance Refresh

RBP Migration: Run RBP Diagnosis Tool RBP Migration for GDPR: Run RBP Diagnosis Tool

 Note

If you are a PE/SPRAC customer, enter and incident with following title: RBP Migration – PE/SPRAC

1. Select Sub Product: (LOD-SF-PLT) Role-Based Permissions.

2. As a customer, you are required to add the Company ID and Company Name for production and non-
production instances, including the data centers.

Provide the following required information when creating your incident

Company ID (non-productive instance)

Company Name (non-productive instance)

Data Center (non-productive instance)

Company ID (productive instance)

Company Name (productive instance)

Data Center (productive instance)

3. In your incident, provide the name and email address of your Account Representative, CEE, and CSM (if
applicable).

Provide the required account representative information

Account Representative First Name, Last Name, and email address (Required)

CEE First Name and Last Name (Required)

CSM First Name and Last Name

 Note
If you do not have a CSM, enter No CSM in this field.

4. If self-service is required, provide the name of your Services Sales Contact.

This information is only required if self-service is needed

Services Sales Executive First and Last Name and email address (Required)

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 29
 5. Are you concerned about data protection and privacy? Yes or No. If yes, this Incident must have the proper
description.

Provide required information about data protection and privacy information

Are you concerned about data protection and privacy and Yes - The incident that you create must have the proper
does your organization plan to leverage data protection description entered. This incident will have a high priority
and privacy functionality? and has been evaluated

No – The RBP Migration will take place before the Fiori ini­
tative and prioritized appropriately

6. Security Complexity can be broken down into Simple or Complex. For more information, see the topic
Assessing Your Security Model Complexity, linked below.

Answer this required question within your incident

Have you evaluated your Security Model Complexity? Yes Simple

or No What is the result? Simple or Complex

Complex

7. In your incident, include the Username and Password for Cloud Support to use for your RBP migration
project. This information would be for one the System Administrators that is already uploaded into (both
production and non-productive instances).

 Note

Ask the customer to confirm that this user has been granted all administrative privileges. (If this has
not been completed, the customer MUST complete prior to enabling RBP). If the customer has SSO
enabled request that Manage Support Access is enabled.

The username and password for your super admin user is required for RBP migration

Username (Super Administrator) Password

8. In your incident, include the Username and Password for Cloud Support to use for your RBP migration
project. This information would be for one the System Administrators that is already uploaded into (both
production and non-productive instances).

The username and password for your super admin user is required for RBP migration

Username (Super Administrator) Password

 Note

Confirm that this user has been granted all administrative privileges. (If this has not been completed,
you MUST grant administrative privileges prior to enabling RBP)

Migrating to Role-Based Permissions

30 CONFIDENTIAL Preparing for RBP Migration
 2. An SAP Cloud Support (CS) representative will be responsible for enabling RBP in the instance. This may take
up to 24 hours to refresh. Please be aware that the level of involvement by CS is primarily to enable Role-Based
Permissions in Provisioning and to create the following initial Groups and Roles. This is in no way a substitute
for an Implementation Partner engagement.
3. SAP Cloud Support will complete the following:
○ Enable Role-Based Permissions and Refresh RBP.
○ Create RBP Groups. See the table below.
○ Create the Super Administrator role and add the user, provided by the customer, to Manage Role-Based
Permissions Access.

Beyond the bullet list above, for any other questions or queries, CS will instruct you to attain an
Implementation Partner engagement to help with your migration.

SAP Cloud Support will Grant Permissions, Create Groups, and will then link them together. This table lists the
various RBP tasks that CS will complete:

SAP Cloud Support (CS) tasks

Set the following permissions:

Grant Permission User Permission General User ○ User Login

○ Organizational Chart Navigation
Permission
Permission
○ Company Info Access
○ User Search

Administrator Permissions ○ Add New Users

○ Manage Users
Manage Users
○ Employee Export
○ Manage Support Access
○ Proxy Management
○ Reset User Account
○ Reset User Passwords
○ Send System Message Email Noti­
fication
○ Set User Status
○ Import Employee Data

Target Group ○ Everyone

 Note
Starting with Everyone is a de­
fault or placeholder at the be­
ginning of this process. The
customer should consider
modifying this Target Group
selection after the handover
from CS.

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 31
 Set the following permissions:

○ Granted Group: System Admin

Granted Group (Add Username) Manage Permission Groups Create
The customer will provide one
New Group Name: Granted Group: Username to CS. This Username
System Administrators will be added to the Granted Group
○ People Pool
These users must be defined in
your SAP SuccessFactors instance
(Pull by Username)
The customer will provide one Sys­
tem Administrator Username to
CS. This Username will be added
to the Granted Group.

 Note
There are three types of adminis­
trators for each customer instance:

The Super Administrator (some­

times referred to as Super User) is
the only user who is allowed to log
on to the system after RBP is ena­
bled. The Super Administrator can
grant other users the right to man­
age role-based permissions. As a
Super Administrator, you can grant
permissions to manage permis­
sions to yourself and any other
consultants working on the project.
In addition, you can grant this per­
mission 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.

 Note

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

Migrating to Role-Based Permissions

32 CONFIDENTIAL Preparing for RBP Migration
 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.

○ Enable Instance Synchronization:

○ Grant permission to the user that the customer provided. The Customer Service representative will
use the Username information from the incident to grant access. The user that is granted permission
will be able to perform the Instance Sync.
○ For more information on Instance Synchronization, please see the Instance Sync: Implementation
and Administration Guide.
○ Once CS completes the above tasks, the incident ticket will be set to Solution Provided and handed over
to the customer for validation and confirmation.

 Note

Any follow up questions or concerns need to be discussed with an Implementation Partner for further
evaluation.

Related Information

How to create a support incident

Prepare Your Instance for Migration [page 27]
Assess Your Security Model Complexity [page 9]

4.2.3 Requesting an Instance Refresh

Request the instance refresh in advance, scheduling can take up to four weeks.

Context

Planning is important as it can take additional time for an Instance Refresh to complete, depending on the modules
that are deployed or the resources available for validation, scheduling may take 2-4 weeks. Your request will be
submitted to refresh the production instance to the non-productive (e.g., sandbox, development, test, or preview)
instances. This refresh is completed to ensure that testing is consistent post-RBP implementation.

 Note

If you have completed an Instance Refresh within the last two months, this step can be skipped.

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 33
Procedure

Go the SAP ONE Support Launchpad to create an incident to request an instance refresh:
○ Create a RBP Migration Request by logging in to the SAP ONE Support Launchpad https://
launchpad.support.sap.com/ . See the Creating Incidents for RBP Migration section for more information.

○  Note

If you have SAP SuccessFactors HCM Suite and Learning integrated, then you need to create an incident to
have both refreshed. See the following Knowledge Base Articles (KBA):

Related Information

LMS Refresh Request process

New Instance Creation, Test Instance, Instance Refresh, Clone - Platform

4.3 Enable Role-Based Permissions

As a super admin, you can enable role-based permissions using the admin center. Use this section to learn how to
enable RBP and understand the pre-requisites to this performing task.

As a super administrator, you can enable role-based permissions. Enabling RBP disables your current security
permissions model allowing you to begin setting up RBP in your system. If you need to disable RBP for testing
purposes, you can disable RBP and your legacy permissions will reactivate in the system.

1. Prerequisites to Enabling RBP [page 35]

Understand the permissions and users you'll need to enable RBP.
2. Enabling RBP in the Admin Center [page 35]
Using your super admin credentials, you can enable RBP from the Platform Feature Settings in the Admin
Center.
3. Granting Administrators Access to RBP [page 36]
To grant access to RBP, you'll need to be logged in as a super administrator.
4. Granting Permission to Platform Feature Settings [page 37]
The Platform Feature Settings page allows you to enable or disable RBP. You must give an administrator
access to this page so they can implement RBP in your system.
5. Disable RBP [page 38]
When testing RBP, you can disable your RBP security model without losing your settings.

Migrating to Role-Based Permissions

34 CONFIDENTIAL Preparing for RBP Migration
4.3.1 Prerequisites to Enabling RBP

Understand the permissions and users you'll need to enable RBP.

Enabling RBP requires that you have a super admin who can access the Platform Feature Settings page. This user
will allow you to grant RBP access to other administrators in your system. Ensure that you have a super admin to
begin the tasks in sections that follow.

● Super Admin User - You must have a super admin user. If you do not, contact customer support to have one
created on your behalf.
● RBP Admin User - You will create this administrator during the process of enabling RBP and you'll have the
ability to give RBP admin permissions to your super admin, or to another administrator in your system.
Separating the super admin and RBP admin privileges can help to ensure that one user does not have
complete authority in the system.

 Note

Platform Feature Settings Permission - Once RBP is enabled, in order to disable RBP, the super admin must be
granted the Platform Feature Settings permission in the RBP environment.

Parent topic: Enable Role-Based Permissions [page 34]

Next task: Enabling RBP in the Admin Center [page 35]

4.3.2 Enabling RBP in the Admin Center

Using your super admin credentials, you can enable RBP from the Platform Feature Settings in the Admin Center.

Context

The assumption of this task is that you have a working super admin user. If you do not have a super admin, contact
Customer Support to have one created in Provisioning. If you are unsure who your super admin is or of their
credentials, contact customer support to reset this user's credentials.

Procedure

1. Log in as your super admin.

2. In the Admin Center tool search bar, search for Platform Feature Settings.
3. On the Platform Feature Settings page, select Enable Role-Based Permissions.

This will disable your current permission settings and enable role-base permissions.

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 35
4. Click Save.

A notification displays saying that RBP was successfully enabled.

5. Log out.
6. Log in.
RBP management access will have propagated in your system.

Task overview: Enable Role-Based Permissions [page 34]

Previous: Prerequisites to Enabling RBP [page 35]

Next task: Granting Administrators Access to RBP [page 36]

Related Information

Creating Incidents for RBP Migration [page 28]

4.3.3 Granting Administrators Access to RBP

To grant access to RBP, you'll need to be logged in as a super administrator.

Prerequisites

Complete the steps in Enabling RBP in the Admin Center.

Procedure

1. Log in to your system with admin credentials. For example, this user might be called SAP Admin.

If you do not have super admin credentials, contact customer support to have one created for you.
2. Go to Admin Center and search for Manage Role-Based Permission Access. to grant RBP management access
to your super admin or to another admin in your system.

The list of users displayed represent everyone in your system who has access to RBP.
3. Select Add User and use the keyword search to find the user you'd like give RBP access to.
4. Select the user's name and click Grant Permission.
5. Log out.
6. Log in.

Migrating to Role-Based Permissions

36 CONFIDENTIAL Preparing for RBP Migration
Results

At this point your chosen administrator has the ability to create groups and roles using RBP.

Task overview: Enable Role-Based Permissions [page 34]

Previous task: Enabling RBP in the Admin Center [page 35]

Next task: Granting Permission to Platform Feature Settings [page 37]

4.3.4 Granting Permission to Platform Feature Settings

The Platform Feature Settings page allows you to enable or disable RBP. You must give an administrator access to
this page so they can implement RBP in your system.

Context

In your previous security model, the super admin had access to the Platform Feature Settings page. Now, in your
RBP environment, the super admin must be given access to this page once again.

Procedure

1. Log in as a super admin.

2. Create a static permission group that contains one or more administrators, including the super admin that you
want to have access to the Platform Feature Settings page.
3. Create a permission role that will contain the Platform Feature Settings Permission so that you can grant this
permission to your administrator group in the next step.
4. Assign the role you created in the previous step, to the static group you created in step 1.

Task overview: Enable Role-Based Permissions [page 34]

Previous task: Granting Administrators Access to RBP [page 36]

Next task: Disable RBP [page 38]

Migrating to Role-Based Permissions

Preparing for RBP Migration CONFIDENTIAL 37
Related Information

Permission Groups [page 55]

Permission Roles [page 61]
Permission Role Assignments [page 66]

4.3.5 Disable RBP

When testing RBP, you can disable your RBP security model without losing your settings.

Context

When implementing RBP in your test or production environments, you can disable RBP as needed. Disabling and
enabling RBP does not delete your previous permissions model settings or your RBP settings.

Procedure

1. Log in as the super admin.

2. In the Admin Center tool search bar, search for Platform Feature Settings.
3. On the Platform Feature Settings page, deselect Enable Role-Based Permissions.

This will disable your RBP permission settings and enable your previous permissions model.
4. Click Save.

A warning message displays to ensure that you intend to disable RBP.

5. Click Ok when the warning message displays.
6. Log out.
7. Log in.

Your security permissions revert to your previous permission model and your settings remain intact.

Task overview: Enable Role-Based Permissions [page 34]

Previous task: Granting Permission to Platform Feature Settings [page 37]

Migrating to Role-Based Permissions

38 CONFIDENTIAL Preparing for RBP Migration
5 Migrating to RBP Using the Migration Tool

The Role-Based Permissions Migration Tool helps you to begin the process of migrating to RBP. The tool allows you
to create some of the most commonly used roles in RBP and assign permissions to those roles based on your
legacy permissions. This tool can also be used to directly add additional role-based permissions.

 Note

It's important to understand that since this tool is used to guide you through the migration process, the
sequence of steps used to migrate with this tool are specific to the RBP Migration Tool.

Using this tool, you’ll have the ability to:

1. Watch the RBP introduction video.

2. Create your own roles by choosing from the list of predefined role templates. (User Login, Everyone (All
Employee), Employee (Self), Manager, Second Manager, Matrix Manager, HR Manager).
3. Assign permissions to your roles by mapping legacy permissions to RBP. You can also use this tool to assign
additional role-based permissions for any of the roles you create using the tool.
4. Grant rules to your roles by assigning access groups and target groups.

 Note

If you have not defined any groups for RBP, you can create groups using the migration tool and use those
groups to grant access to the roles you created in the tool. You can also update any default rules already
associated with the role.

5. Review the permissions you've enabled and publish the role.

 Note

Until you publish a role template, it remains in draft mode. You can have five role templates in draft at one
time. After creating five role drafts, you must publish at least one role in order to create another role.

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 39
 Is This Tool Recommended for Me? [page 40]
The RBP migration tool uses your legacy permission structure to help you enable and map some of your
legacy permissions to role-based permissions. This tool is intended to assist small organizations who wish
to create a small set of roles in their system. It's also intended as a starting point for larger organizations to
help you get started with your RBP migration.

How to Use the RBP Migration Tool [page 41]

This image provides a high-level task workflow for migrating with the RBP Migration Tool. The sequence in
this workflow is specific to the migration tool.

5.1 Is This Tool Recommended for Me?

The RBP migration tool uses your legacy permission structure to help you enable and map some of your legacy
permissions to role-based permissions. This tool is intended to assist small organizations who wish to create a
small set of roles in their system. It's also intended as a starting point for larger organizations to help you get
started with your RBP migration.

 Note

The migration tool will help you get started, ensure that you refer to the section: Migrating to RBP, to manage
your RBP migration.

To help determine if the migration tool can help you with your RBP migration, you should answer yes to the
following questions.

● Do you need create and add permissions to the following roles? (User Login, Everyone (All Employee),
Employee (Self), Manager, Second Manager, Matrix Manager, HR Manager
● When assigning permissions using a relationship hiearchy, do you require only a single relationship between
the reporting lines of granted and target users?
For example, does the target or granted user have a relationship of employee to the HR manager.

Migrating to Role-Based Permissions

40 CONFIDENTIAL Migrating to RBP Using the Migration Tool
● Do you want to use predefined role templates to get started with your organization?

 Note

We recommend that you seek an implementation engagement when migrating Compensation and Recruiting.

Related Information

Legacy Permissions Supported in the RBP Migration Tool [page 45]

Migrating to RBP [page 54]
Engage with an Implementation Partner [page 16]

5.2 How to Use the RBP Migration Tool

This image provides a high-level task workflow for migrating with the RBP Migration Tool. The sequence in this
workflow is specific to the migration tool.

To perform your RBP migration outside of the migration tool, use the instructions described in the Migrating to RBP
section: Migrating to RBP [page 54]

● Defining Roles in the RBP Migration Tool [page 42]

● Assigning Permissions to a Role in the RBP Migration Tool [page 44]
● Granting Rules to Roles in the Migration Tool [page 49]
● Review and Publish [page 53]

Defining Roles in the RBP Migration Tool [page 42]

The first step in migrating to role-based permissions is to select the permission role template that you wish
to create in your system.

Assigning Permissions to a Role in the RBP Migration Tool [page 44]

The second step in the RBP Migration Tool workflow is to assign permissions to the role. Each role template
comes with some default role-based permissions, but you'll need to add additional permissions to your
roles in order to complete its definition and control access to your system.

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 41
 Granting Rules to Roles in the Migration Tool [page 49]
After you've assigned permissions to the role you created, you'll need to define who will have access to the
permissions contained in the role. You can do that by adding a rule to the role. A rule contains a group of
users who you want to have access to the functionality given by the role. In some cases that rule will be
required to contain a target group; a group for whom users granted the role can perform actions upon other
users. If you need to define an RBP access group, select Define Group and use the link to the Dynamic
Group document to understand the steps required to complete this task.

Review and Publish [page 53]

After you've assigned permissions to your role and granted the role to your groups, you can review the role-
based permissions that you have enabled for the role.

5.2.1 Defining Roles in the RBP Migration Tool

The first step in migrating to role-based permissions is to select the permission role template that you wish to
create in your system.

Context

Using the migration tool, you'll need to create roles, choosing from those supported in the migration tool.

Procedure

1. Select one of the predefined role templates by clicking Create a Role.

2. When the list of possible role templates displays, select the role you want to define.

At this point, you can rename the role template you've selected.
3. Select Ok

The role the is now in draft mode and you can update the details of this role in the migration tool until its
published.

 Note

You can have up to five role templates in draft at once, at that point in order to create other roles, you must
publish at least one role.

Next Steps

Continue to Assigning Permissions to a Role in the RBP Migration Tool.

Migrating to Role-Based Permissions

42 CONFIDENTIAL Migrating to RBP Using the Migration Tool
Related Information

Assigning Permissions to a Role in the RBP Migration Tool [page 44]

5.2.1.1 Roles Supported in the RBP Migration Tool

The RBP migration tool supports creation of some of the basic roles that you'll need in your system. Some of these
roles contain default permissions and default group assignments that you can update and customize.

Supported Roles

The migration tool contains some predefined role templates that you can use to get started when defining the roles
you'll need for your migration.

 Note

When making changes to role templates, ensure that your descriptions are also updated.

Default Role-Based Permis­

Role sions Default Access Group Default Target Group

User Login User Login Everyone None

Everyone(All Employee) ● Live Profile Access Everyone (All Employee) All (Employee
● Organization Chart Navi­
gation Permission†
● Company Info Access†
● User Search†
● Employee Data

To view the Employee Data

fields that are enabled by de­
fault select the following from
Everyone (All Employee) role
with in the migration tool:

Assign Additional
Permissions Employee
Data

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 43
 Default Role-Based Permis­
Role sions Default Access Group Default Target Group

Employee(Self) ● Employee Data Everyone (All Employee) Employee(Self)

To view the Employee Data

fields that are enabled by de­
fault select the following from
Employee (Self) role with in
the migration tool:

Assign Additional
Permissions Employee
Data

HR None All HR Managers All HR Reports

Manager None All Managers All Direct Reports

Second Manager (Optional None All Second Managers All Second Reports
Role)

Matrix Manager None All Matrix Managers All Matrix Reports

5.2.2 Assigning Permissions to a Role in the RBP Migration Tool

The second step in the RBP Migration Tool workflow is to assign permissions to the role. Each role template comes
with some default role-based permissions, but you'll need to add additional permissions to your roles in order to
complete its definition and control access to your system.

Context

On the Assign Permissions screen, you'll see a list of legacy permissions and the categories they belong to. The
legacy permissions listed represent a subset of the possible permissions in your system that you can migrate.
Based on the products you have deployed in your system, choose the legacy permissions that you want to map to
role-based permissions.

Procedure

1. After you've selected a role template, you can map legacy permissions to the role by selecting Assign
Pemissions.
2. From the Administrative Privileges section, slide the toggle to the Yes position, for the permissions you want to
map to RBP.

The permissions you choose will be enabled for the role.

Migrating to Role-Based Permissions

44 CONFIDENTIAL Migrating to RBP Using the Migration Tool
3. From the Default User Permissions section. Slide the toggle to Yes for the permissions you want to map to RBP.

After you've chosen the administrative and user legacy permissions to map to RBP, you may also want to
directly assign some role-based permissions to the role that you're defining. You can add role-based
permissions directly to your role by selecting Assign Additional Permissions.
4. When you've added your permissions to the role, click Next.

For example, the Everyone (all) role might have the Live Profile permission mapped from legacy permissions to
role-based permissions as shown in the display.

Next Steps

Continue to Granting Rules to Roles in the Migration Tool.

Related Information

Assigning Permissions to a Role [page 50]

Granting Rules to Roles in the Migration Tool [page 49]

5.2.2.1 Legacy Permissions Supported in the RBP Migration

Tool

The RBP Migration tool maps the following legacy permissions to role-based permissions.

Category Legacy Permission Corresponding Role-Based Permission

Manage Calibration Manage Permission for Executive Review Manage Permission for Executive Review

OData API Calibration Export OData API Calibration Export

Mass Create Calibration Sessions Mass Create Calibration Sessions

Manage Calibration Settings Manage Calibration Settings

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 45
Category Legacy Permission Corresponding Role-Based Permission

Manage Calibration Templates Manage Calibration Templates

Manage Calibration Sessions Manage Calibration Sessions

Managing Development Import Learning Administrator and Edu­ Import User Relationship for Learning
cational Representative Administrator and Educational Represen­
tative

Import Learning Activity by Web Service Import Learning Activity by web service

Manage Suggested Roles Manage Suggested Roles

Admin Career Development Plan Export Admin Career Development Plan Export
Data Data

Manage Learning Activity Catalogs Manage Learning Activity Catalogs

Manage Learning Activity to Competency Manage Learning Activity to Competency

mappings mappings

Mapping Learning Activities to Compe­ Mapping Learning Activities to Compe­

tencies tencies

Career Development Plan Access (CDP) Career Development Plan (CDP) Access Career Development Plan (CDP) Access
Permission Permission

Career Development Plan (CDP) Learn­ Career Development Plan (CDP) Learn­
ing Activity Mass Add ing Activity Mass Add

Career Worksheet Suggested Roles Ac­ Career Worksheet Suggested Roles Ac­
cess Permission cess Permission

Managing Documents Delete Documents Delete Documents

Import Overall Scores Import Overall Scores

Manage Document Visibility Manage Document Visibility

Restore Deleted Documents Restore Deleted Documents

Approve Document Approve Document

Change Document Date Change Document Date

Admin Access to Forms OData API Admin Access to Forms OData API

Mass Route Document Forward Mass Route Document Forward

Mass Route Document Backward Mass Route Document Backward

Modify Form Route Map Modify Form Route Map

Migrating to Role-Based Permissions

46 CONFIDENTIAL Migrating to RBP Using the Migration Tool
Category Legacy Permission Corresponding Role-Based Permission

Route Completed Documents Route Completed Documents

Route Document Route Document

Include Completed Documents Include Completed Documents

Allow Adding of a Step Allow Adding of a Step

Route Signature Stage Document Route Signature Stage Document

Sign Document Sign Document

Manage Objectives Group Objective Creation Group Objective Creation

Group Objective Assignment Group Objective Assignment

Import Objectives Import Objectives

Target Population Target Population

Import/Export Objectives library Import/Export Objectives library

Objective Management Feature Settings Objective Management Feature Settings

Import/Export user and objective plan Objective Plan Permissions

permission association

Manage Objective Execution Manage Configuration of Objective Exe­ Manage Configuration of Objective Exe­
cution cution

Access Execution Map Access Execution Map

Access Meeting Agenda Access Meeting Agenda

Access Status Report Access Status Report

Form Template Administration Form Templates Form Templates

Comprehensive template configuration Comprehensive template configuration

for PMv12 for PMv12

Mass Create Form Instances (Launch Mass Create Form Instances (Launch
forms now) forms now)

Schedule Mass Form Creation (Launch Schedule Mass Form Creation (Launch
forms later) forms later)

Rating Scales Rating Scales

Routing Maps Routing Maps

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 47
Category Legacy Permission Corresponding Role-Based Permission

Export Performance Management Form Export Performance Management Form

Data Data

Manage Presentations Manage Presentation Manage Presentation

Manage Talent Card Manage Talent Card Configuration Manage Talent Card Configuration

Reports Permission List View List View

Ad Hoc Report Builder Standard Reports Ad Hoc Report Builder Standard Reports
Bin (Employee Central Customers Only) Bin (Employee Central Customers Only)

Create Ad-Hoc Report Create Ad-Hoc Report

Run Ad-Hoc Report Run Report

Publish Scorecard Pixel Perfect Talent Card

Scorecard XML Export Pixel Perfect Talent Card Export XML

Manage Security Spreadsheet Report Permission Spreadsheet Report Privilege

Learning Admin Access Permission Learning Admin Access Permission

Performance Management Access Per­ Performance Management Access

mission

Permission to Create Forms Permission to Create Forms

Permission to Create Notes Permission to Create Notes

Dashboards/Reports Analytics Tiles and Dashboards Analytics Tiles and Dashboards

Processes and Forms Processes and Forms

Rating Scales Rating Scales

Performance Management Date Range Performance Management Date Range

Thresholds Thresholds

Trending Trending

Filtering Options Filtering Options

Individual Portlets Individual Portlets

Portlet Permissions Portlet Permissions

List Views List Views

Migrating to Role-Based Permissions

48 CONFIDENTIAL Migrating to RBP Using the Migration Tool
Category Legacy Permission Corresponding Role-Based Permission

Manage Ownership Manage Ownership

Restore Deleted Reports Restore Deleted Reports

Calibration Management Privilege View Calibration Tab View Calibration Tab

Create Report Calibration Activity Calibration Activity

Calibration Org Chart Coverage Calibration Org Chart Coverage

Calibration Calibration

Run Report Calibration Activity Calibration Activity

Calibration Org Chart Coverage Calibration Org Chart Coverage

Calibration Calibration

Live Profile Access Live Profile Access Live Profile Access

System Properties Import Extended User Information Import Extended User Information

Export Extended User Information Export Extended User Information

Learning Learning Access Permission Learning Access Permission

5.2.3 Granting Rules to Roles in the Migration Tool

After you've assigned permissions to the role you created, you'll need to define who will have access to the
permissions contained in the role. You can do that by adding a rule to the role. A rule contains a group of users who
you want to have access to the functionality given by the role. In some cases that rule will be required to contain a
target group; a group for whom users granted the role can perform actions upon other users. If you need to define
an RBP access group, select Define Group and use the link to the Dynamic Group document to understand the
steps required to complete this task.

Context

The role you're creating may contain at least one rule by default and this rule may contain one group and one target
group. You can edit or remove this rule or you can add additional rules. A rule will contain at least one access group
but may also contain a target group. If you haven't defined any groups in your system, you'll need to select Define
Groups.

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 49
Procedure

1. From the Assign Pemissions screen, select Associate Rules.

2. If you've created groups that can be used as access groups or target groups, select Add Rule.
3. When the Grant this role to screen displays select the permission group you'd like to give access to this role.

To add a rule, refer to the following topic: Assigning Permissions to a Role [page 50]
4. If you need to define groups in order to complete step 3, select Define Group.

To define a group, refer to the following topic: Creating Dynamic Permission Groups [page 59]
5. After you've assigned groups and target groups to the role, click Next.

For example, a rule for your role templates may contain multiple groups separated by a comma with a target
group as shown in the display below.

Assigning Permissions to a Role [page 50]

After creating groups and roles, you'll need to assign permission roles to your employee groups.

Creating Dynamic Permission Groups [page 51]

Dynamic permission groups are generated automatically when the attributes of employees match the
group selection criteria. Administrators can create and manage dynamic permission groups for both
employees and external users.

5.2.3.1 Assigning Permissions to a Role

After creating groups and roles, you'll need to assign permission roles to your employee groups.

Procedure

1. In the Permission Settings section, click the Permission button to specify the permission you want to assign to
the role. The Permission Settings window opens.
2. On the left side of the page, you'll see the different permission categories. Click a permission category to reveal
the different permissions.

The list of permissions associated with this category is displayed.

Migrating to Role-Based Permissions

50 CONFIDENTIAL Migrating to RBP Using the Migration Tool
3. Select the checkboxes next to the permissions you'd like to grant to the role.
4. Click the Done button when you finish marking your selections.
5. Click Save Changes.

Next Steps

Assign a target population, if your role indicates that a target is needed.

5.2.3.2 Creating Dynamic Permission Groups

Dynamic permission groups are generated automatically when the attributes of employees match the group
selection criteria. Administrators can create and manage dynamic permission groups for both employees and
external users.

Procedure

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

2. Click Create New to create a new permission group.

The Permission Group page opens.

3. Enter a name for your permission group in the Group Name field.
4. Choose a User Type for your group.

The available user types vary depending on how your system is configured. Possible values may include:

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 51
 ○ Employee (default)
○ External Learning User

 Note

The External Learning User option is only available if you have Learning enabled in your system.

When defining a dynamic group for an external learning user, you can identify an External Source Channel to
complete the criteria for inclusion. This allows external learning users to be defined based on the source of
origin. The external source channel is only available to SAP SuccessFactors Learning customers. The External
Learning User must be enabled in Provisioning for external learner and external source channel to be available.

 Tip

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

5. Choose the group selection criteria from the People Pool, in the Choose Group Members section.

Depending on the complexity of your permission group selection criteria, you can choose multiple people
pools.

6. In the Search Results screen, enter a search term or click the  search, to display all available values.

For some categories, a smaller pop-up window appears where you can enter additional values or information,
such as Time Zone settings. If you select the Team View category, you can use hierarchical relationships to
specify the group. This allows you to apply rules such as: everybody in Carla Grant's team, all levels deep.
7. Make your selection and click Done.
8. If you want to add another condition for defining the people pool, click Add another category and choose a
category and item. If you use two or more categories, this functions as an AND operation, that is, only users are
selected who meet all selection criteria.

 Example

If you want to create a group of sales employees working in the US, you would need to choose the category
Department and select Sales. You add a second category Country and select USA.

9. Complex group definitions may require you to use multiple people pools. If you use two or more people pools,
these people pools functions as an OR operation, that is, all users are selected who fulfill the selection criteria
of at least one pool.

Click Add another People Pool and then add categories and items.

 Example

You have two different offices: An office in Chicago and an office in Boston. Each office has a Sales team and
a Finance team. You only want to include Sales employees from the Chicago office and Finance employees
from the Boston office. You'll need to create two separate pools then.

 Note

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

10. If there are employees you'd like to exclude from the Permission Group definition, select them in the Exclude
these people from the group section.

Migrating to Role-Based Permissions

52 CONFIDENTIAL Migrating to RBP Using the Migration Tool
11. If you want to prevent the group being updated automatically when new employees match the selection
criteria, click Lock group.
12. Click Done to complete the process.

5.2.4 Review and Publish

After you've assigned permissions to your role and granted the role to your groups, you can review the role-based
permissions that you have enabled for the role.

The legacy permissions that you have mapped to role-based permission and any additional role-based permissions
that you've added to your role are ready for review and publishing. You can view your list of permissions that require
a target population and those that do not require a target population. You can also review any rules that you've
defined for this role. When you're satisfied with the role details, select Publish.

When the role is published you can manage it using Manage Permission Roles in the Admin Center.

When you've completed this process for all the roles you wish to create, you can test your implementation and
ultimately copy your configurations to production by reviewing the following:

● Testing Your Role-Based Permissions: Testing Your Role-Based Permissions [page 75]
● Check Tool: Check your RBP configurations: Using the Check Tool [page 79]
● Copying configuration to the production Instance: Copying Configuration to the Production Instance [page
87]

Migrating to Role-Based Permissions

Migrating to RBP Using the Migration Tool CONFIDENTIAL 53
6 Migrating to RBP

When you've complete your prerequisites and prepration steps to RBP migration, use this section to learn how to
create your groups and roles and to grant permission.

What are Role-Based Permissions? [page 54]

Role-Based Permissions (RBP) is a security model that allows you to restrict and grant access to your SAP
SuccessFactors HCM Suite. RBP controls access to the applications that employees can see and edit. This
is a suite-wide authorization model that applies to the majority of the SAP SuccessFactors products.

6.1 What are Role-Based Permissions?

Role-Based Permissions (RBP) is a security model that allows you to restrict and grant access to your SAP
SuccessFactors HCM Suite. RBP controls access to the applications that employees can see and edit. This is a
suite-wide authorization model that applies to the majority of the SAP SuccessFactors products.

Open this video in a new window

The RBP security authorization model uses groups and roles to organize employees (groups) and permissions
(roles) to control access to your system; By organizing employees into groups and permissions into roles you can
assign a group of employees the same set of permissions by assigning them a role.

 Note

RBP is approved for organizations with up to 300,000 employees. We will continue to raise this bar in the
future. When in doubt, contact customer support.

Role-based permissions contain three main elements: Permission Groups, Permission Roles, and Target
Populations. Permission groups are a set of employees who share certain attributes such as City or Job Code and
require access to a similar set of tasks within your system. Roles are defined as a set of permissions. You can assign
the permission roles, you define, to a permission group and if the role requires that you define a target population,
meaning a group to perform tasks for, you'll assign the target population when you define the role.

Target populations are groups that are assigned to permission roles when the permission granted is performed on
behalf of other employees.

 Tip

We recommend that you create groups before creating roles so that during role creation, you can select the
group for which to grant the role. In addition, you’ll need defined groups for roles that require a target
population.

Permission Groups [page 55]

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.

Migrating to Role-Based Permissions

54 CONFIDENTIAL Migrating to RBP
 Permission Roles [page 61]
RBP uses permission roles to group a set of permissions. After grouping the permissions into a role, you
can assign the role to a group of users, granting them access to certain tasks and features in your system.

Permission Role Assignments [page 66]

You can assign a permission role to everyone or to a subset of employees, determined by permission
groups, target populations, or by relationships. When defining a role in RBP, you can assign the role to a
group that you've created or you can assign roles based on hierarchical relationships. Some roles will
require that you also assign target populations, they're only necessary for certain permissions in a role and
your system will notify you when a target population is required.

6.1.1 Permission Groups

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

 Example

There might be a permission group called "Human Resources in US", which lists all US-based employees who
work in the HR department. To define this group, you would specify that users must match the selection criteria
"Country = United States" and "Department = HR".

 Note

The attributes or selection criteria that are available for defining groups are configurable.

In RBP, you can assign permission roles to permission groups. In addition, you use groups to define the target
population a granted user has access to.

 Example

The group "Human Resources in US" might have access to the group "US Employees".

Groups configured with criteria other than specific user names are called dynamic (as opposed to static),
which means that the assignment of employees into and out of a group is automated. For example, a group of
granted users can be “All employees in the Sales department”. As employees are transferred into and out of the
sales department, their permissions will automatically adjust. This automation will save you time and money.
This is especially beneficial for large organizations that need higher levels of administrative efficiency.

Creating Static Permission Groups [page 56]

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

Creating Dynamic Permission Groups [page 59]

Dynamic permission groups are generated automatically when the attributes of employees match the
group selection criteria. Administrators can create and manage dynamic permission groups for both
employees and external users.

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

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 55
 You can edit, copy, and delete static or dynamic permission groups. For dynamic groups, you can also view
the group's change history.

6.1.1.1 Creating Static Permission Groups

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

Procedure

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

2. Click Import Static Groups to create or modify a group.
3. Select between Full Replace or Delta Replace.
A full replace, creates or entirely replaces a group, while a delta replace adds members to an already existing
group.

4. Download a blank CSV template after you've chosen an import type. The Full Replace template has two column
headers, GROUPNAME and USERID. The Delta Replace has an additional Action column.
5. For each user that you add to a group, add the group name to the GROUPNAME column and user's ID to the
USERID column.

 Note

For new users, you can create user IDs in the upload file.

Migrating to Role-Based Permissions

56 CONFIDENTIAL Migrating to RBP
  Note

Character encoding of your file should be Unicode(UTF-8). The maximum file size is 20MB. If your import
file exceeds 20MB, you can either split the file into several smaller files or request Professional Services to
modify the system configuration file.

6. Select the file with your data by clicking Choose File.

7. Click Validate File to validate file format, file size, etc.
8. If the validation is successful, click Upload to import the static permission groups.

If your file has errors, they display at the top of the Import Static Group window.

 Note

For one group type, a maximum of two jobs can run at the same time.

Results

After the upload completes, the system sends you a notification with success or error messages. Successfully
created groups display in the group list after refreshing your system.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 57
6.1.1.1.1 Adding Individual Members to Static Groups

You can add members to a static group in your system or by importing an excel file to your system.

Procedure

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

2. Click the name of the static group you're updating.

The Permission Group screen displays.

3. To add a user to a static group, click Add User.
4. Search for the users you'd like to add to the group.

Entering keywords in the search field displays user names.

5. Select each user you want to add to the group.

Each user you select automatically displays in the right pane.

6. Click Done.

The users you selected are added to the group immediately.

Migrating to Role-Based Permissions

58 CONFIDENTIAL Migrating to RBP
6.1.1.1.2 Deleting Members from Static Groups

Although you add members to a static group using a spreadsheet, you can delete static group members using the
system.

Procedure

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

2. Click the name of the static group you're updating.

The Permission Group screen displays.

3. Select the users that you want to delete from the group.
4. Click Delete.

The list of users updates immediately.

5. Click Close.

Results

Deleted members will no longer have access to the tasks or data of the group.

6.1.1.2 Creating Dynamic Permission Groups

Dynamic permission groups are generated automatically when the attributes of employees match the group
selection criteria. Administrators can create and manage dynamic permission groups for both employees and
external users.

Procedure

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

2. Click Create New to create a new permission group.

The Permission Group page opens.

3. Enter a name for your permission group in the Group Name field.
4. Choose a User Type for your group.

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

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 59
  Note

The External Learning User option is only available if you have Learning enabled in your system.

When defining a dynamic group for an external learning user, you can identify an External Source Channel to
complete the criteria for inclusion. This allows external learning users to be defined based on the source of
origin. The external source channel is only available to SAP SuccessFactors Learning customers. The External
Learning User must be enabled in Provisioning for external learner and external source channel to be available.

 Tip

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

5. Choose the group selection criteria from the People Pool, in the Choose Group Members section.

Depending on the complexity of your permission group selection criteria, you can choose multiple people
pools.

6. In the Search Results screen, enter a search term or click the  search, to display all available values.

For some categories, a smaller pop-up window appears where you can enter additional values or information,
such as Time Zone settings. If you select the Team View category, you can use hierarchical relationships to
specify the group. This allows you to apply rules such as: everybody in Carla Grant's team, all levels deep.
7. Make your selection and click Done.
8. If you want to add another condition for defining the people pool, click Add another category and choose a
category and item. If you use two or more categories, this functions as an AND operation, that is, only users are
selected who meet all selection criteria.

 Example

If you want to create a group of sales employees working in the US, you would need to choose the category
Department and select Sales. You add a second category Country and select USA.

9. Complex group definitions may require you to use multiple people pools. If you use two or more people pools,
these people pools functions as an OR operation, that is, all users are selected who fulfill the selection criteria
of at least one pool.

Click Add another People Pool and then add categories and items.

 Example

You have two different offices: An office in Chicago and an office in Boston. Each office has a Sales team and
a Finance team. You only want to include Sales employees from the Chicago office and Finance employees
from the Boston office. You'll need to create two separate pools then.

 Note

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

10. If there are employees you'd like to exclude from the Permission Group definition, select them in the Exclude
these people from the group section.
11. If you want to prevent the group being updated automatically when new employees match the selection
criteria, click Lock group.

Migrating to Role-Based Permissions

60 CONFIDENTIAL Migrating to RBP
 12. Click Done to complete the process.

6.1.1.3 View, Edit, Copy, and Delete Permission Groups

You can edit, copy, and delete static or dynamic permission groups. For dynamic groups, you can also view the
group's change history.

Context

 Note

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

Procedure

1. Go to the Admin Center Tools and search for Manage Permission Groups.
2. In the Manage Permission Groups screen, click the Take Action dropdown menu next to the permission group
you want to modify.
3. Choose the desired action.

6.1.2 Permission Roles

RBP uses permission roles to group a set of permissions. After grouping the permissions into a role, you can assign
the role to a group of users, granting them access to certain tasks and features in your system.

Permission roles consist of a set of permissions that give employees access rights to an employee or a group of
employees. As such an employee or a group that has been granted with a permission role has access to certain

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 61
aspects of the SuccessFactors application or to aspects of employee data. With this access, they can perform
functions within the application for other groups of employees.

Role-based permissions allow you to grant a role to a specific employee, a manager, a group, or to all employees in
the company. The roles can provide very granular permissions, as this example illustrates:

 Example

There may be roles such as "HR Compensation and Benefits Manager", "HR Manager for Sales", and "HR
Learning and Development Manager". While all three are HR managers, their roles have been distinctly carved
out — one handling compensation and benefits, another handling the sales team, and the third handling
Learning and Development.

When your permissions roles consist of one or more permissions that require a target population, you'll need to
specify a target to complete creation of the role. Roles that require a target population will contain a permission
that gives a group access to perform actions or view information for other employees.

 Example

A Manager may have a role where one permission allows the manager to modify the salary for all of their direct
reports. In this example, the manager's direct reports represent the target population needed for the
permission role.

 Note

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

Creating Permission Roles [page 63]

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

Assigning Permissions to a Role [page 50]

After creating groups and roles, you'll need to assign permission roles to your employee groups.

View, Edit, Copy, and Delete Permission Roles [page 64]

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

Creating a New Role for External Users [page 65]

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

Migrating to Role-Based Permissions

62 CONFIDENTIAL Migrating to RBP
6.1.2.1 Creating Permission Roles

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

Procedure

1. Go to the Admin Center.

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

The Permission Role Detail page opens.

4. In the Role Name, type a name describing of what the role allows you to do.
5. In the Description, provide a statement describing what the role allows an employee to do. Add a note about
when the role was created and by whom.

After this role is successfully created, the new role will be listed on the Permission Role List page.
6. Click Save Changes.

Results

You have a permission role and you can now add permission and assign it to a group.

Next Steps

After you've created a permission role, you'll need to assign permissions to the new role.

6.1.2.2 Assigning Permissions to a Role

After creating groups and roles, you'll need to assign permission roles to your employee groups.

Procedure

1. In the Permission Settings section, click the Permission button to specify the permission you want to assign to
the role. The Permission Settings window opens.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 63
2. On the left side of the page, you'll see the different permission categories. Click a permission category to reveal
the different permissions.

The list of permissions associated with this category is displayed.

3. Select the checkboxes next to the permissions you'd like to grant to the role.
4. Click the Done button when you finish marking your selections.
5. Click Save Changes.

Next Steps

Assign a target population, if your role indicates that a target is needed.

6.1.2.3 View, Edit, Copy, and Delete Permission Roles

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

Context

When you copy a role, only the permissions get copied over. You will need to manually grant employees access to
this new role.

Migrating to Role-Based Permissions

64 CONFIDENTIAL Migrating to RBP
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.

6.1.2.4 Creating a New Role for External Users

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

The external user role can be granted to the Everyone (External Learner) group. Permissions for the external user
role can be set to grant access to SAP Jam and SAP SuccessFactors Login, Learning modules, and Mobile.

For complete details about External Learning, please refer to the Offering Learning to the Extended Enterprise
guide.

6.1.2.4.1 External User Management

If you have external users, consider creating a management system for them so that you can maintain their access.

When you have external users in your extended enterprise, your plan for maintaining them should include: resetting
user passwords, granting access, and so on. In most cases, you manage external users as you do any other users.

One exception is target populations. External users can be a unique target population. For example, if you want to
manage external users in learning, you must add All (External Learning) to the target population of users managed
by the administrator.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 65
6.1.2.4.2 Mapping External Users from Learning Sites to SAP
SuccessFactors Roles

Create a role mapping for external users so that users who log in through SAP SuccessFactors Learning sites are
granted the correct permissions.

Prerequisites

Role Based Permissions (RBP) must be enabled.

Procedure

1. Log in and go to Admin Center.

2. In Tools, click See All.
3. In Search Tools, type Manage Permission Roles and then click Manage Permission Roles.
4. Click Create New Role For External User.
5. In User Type, select External Learner, and then click Done.
6. Type a name and description for the role and then click Permissions.

The Permission Settings page opens.

7. In User Permissions General User Settings , select User Login.

8. In User Permissions Learning , select Learning Access Permission.

You can select additional permissions. For example, you can grant the external users access to SAP Jam.
9. Click Done.

You return to the Permission Role Detail page.

10. Click Add.

The Grant this role to... page opens.

11. In Grant role to, select Everyone (External Learner).
12. Click Done.

You return to the Permission Role Detail page.

13. Click Save Changes.

6.1.3 Permission Role Assignments

You can assign a permission role to everyone or to a subset of employees, determined by permission groups, target
populations, or by relationships. When defining a role in RBP, you can assign the role to a group that you've created
or you can assign roles based on hierarchical relationships. Some roles will require that you also assign target

Migrating to Role-Based Permissions

66 CONFIDENTIAL Migrating to RBP
populations, they're only necessary for certain permissions in a role and your system will notify you when a target
population is required.

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

 Note

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

● Target Population: Depending on the permissions included in the role, you might also have to define the target
population. Not all permissions require you to define a target population. For example, if the permission
includes just the access to an application (such as the Learning Access Permission), there is no need to add a
target group. For certain permissions, in the Permission settings screen, a target population must be defined.
This is identified by the "t" icon next to the permission name with the following text displayed: t= Target needs
to be defined.

 Note

A target population for an external Learning user can be defined two ways:
○ Select Everyone (External Learner)
○ Select Target population of: and click Select, to select groups

● Relationships: Access groups can be defined using relationships (for example, manager-employee
relationship) that are derived from the job relationship object. These relationships can be hierarchical or non-
hierarchical. You can find more information in the following chapter Using Relationships to Grant Permissions
[page 71].

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 67
●  Note

If you allow the respective managers to have the same permissions, this may have a negative impact on the
performance. The hierarchy then has to be checked whenever such a manager tries to access an element
which was permissioned this way.

6.1.3.1 Assigning Permission Groups to a Role

After creating your roles, you must assign the role to a group of employees. This ensures that employees are given
access the permissions they need to perform their tasks.

Procedure

1. Go to the Admin Center.

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

Migrating to Role-Based Permissions

68 CONFIDENTIAL Migrating to RBP
 6. Click Select to select the access groups you wish to assign to this permission role.

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

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

 Example

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

8. Click Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.
9. Click Save Changes to complete creating the role.

Next Steps

If required, assign a target population to your role.

6.1.3.2 Assigning Target Populations to a Role

Target populations are assigned to roles that require tasks to be performed on behalf of another employee.

Context

Target populations allow you to give employees such as managers and administrators access to data or tasks that
need to be maintained for other employees. Depending on the permissions included in the role, you may need to
define the target population. Not all permissions require you to define a target population. For example, if the
permission includes just the access to an application (such as the Learning Access Permission), there is no need to
add a target group. For certain permissions, in the Permission settings screen, a target population must be
defined. This is identified by the "t" icon next to the permission name with the following text displayed: t= Target
needs to be defined.

Procedure

1. Go to the Admin Center.

2. In the Tools Search, search for Manage Permission Roles.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 69
3. Select one of the permission roles you created.
4. In the Grant this role to section of the Permission Detail screen, click Add.
5. Select Everyone or choose Target population of to select a group .

6. Click Select to select the target groups that you want to assign to this permission role.
7. Exclude Granted Users:

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

 Example

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

8. Click Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.
9. Click Save Changes to complete creating the role.

Migrating to Role-Based Permissions

70 CONFIDENTIAL Migrating to RBP
6.1.3.3 Using Relationships to Assign Permissions

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

General Relationship Types: Hierarchical relationships are characterized by a reporting line between the granted
user and the target user. These are relationships between employees and their managers, and employees and their
second managers or alternate managers. Non-hierarchical relationships on the other hand are single-level
relationships. These include the relationship of an employee to the HR manager, the matrix manager and custom
manager. While each employee can have only one Manager, one Second Manager and one HR Manager, they can
have multiple Matrix Managers and Custom Managers.

Employee Central Only: If employees have global assignments (that is, a job in another country), they have both a
home manager and a host manager. In addition, they have a home HR manager and a host HR manager. All
managers need to have access to both the home jobs of the employees as well as to the host jobs of the employees.
This is covered by the following additional relationship types for global assignments:

Employee Central Only: Relationship Types for Global As­

The Five General Relationship Types signments

Manager Home Managers

Second/Alternate Manager Home HR Managers

HR Manager Host Managers

Matrix Manager Host HR Managers

Custom Manager

6.1.3.3.1 Assigning Permissions using Relationships

After defining permission roles, you can use relationships to establish access to those roles instead of permission
access groups.

Context

Using relationships to grant access permissions gives you the added ability to define access and target populations
using your organizations hierarchy.

Procedure

1. Go to the Admin Center.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 71
2. In the Tools Search, search for Manage Permission Roles.
3. Select one of the permission roles you created.
4. In the Grant this role to section of the Permission Detail screen, click the Add to select the employees to be
granted this permission.
5. When the Grant this role to screen displays, select a relationship type.

These relationships can be hierarchical or non-hierarchical.

 Note

If you allow the respective managers to have the same permissions, this may have a negative impact on the
performance. The hierarchy then has to be checked whenever such a manager tries to access an element,
which was permissioned this way.

6. Assign a target population to the role:

Depending on the permissions included in the role, you might also have to define the target population. Not all
permissions require you to define a target population. For example, if the permission includes just the access to
an application (such as the Learning Access Permission), there is no need to add a target group. For certain
permissions, in the Permission settings screen, a target population must be defined. This is identified by the
"t" icon next to the permission name with the following text displayed: t= Target needs to be defined.
○ Target Population: A target population for an external Learning user can be defined two ways:
○ Select Everyone (External Learner)
○ Select Target population of: and check the checkbox to Select... to define the group

Migrating to Role-Based Permissions

72 CONFIDENTIAL Migrating to RBP
 7. Exclude Granted Users:

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

 Example

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

8. Click Done to assign this role to the defined users. You are taken back to the Permission Role Detail page.
9. Click Save Changes to complete creating the role.

6.1.3.3.2 Specifying the Hierarchy Depth

Understand how to use hiearchy depth when assigning permissions to your users.

When granting permissions using hierarchical relationships, you can specify how many levels down to go in the
hierarchy for the target population. For example, you can indicate that Managers can see performance ratings on
their direct reports (1 level deep), or allow it to go deeper into their team, that is 2 levels down or all levels.

When granting permissions to non-hierarchical relationships (HR, Matrix and Custom Managers), you can follow
this non-hierarchical relationship for only one level. Beyond the first level, you can cross over to the standard
manager hierarchy if desired to go deeper.

Migrating to Role-Based Permissions

Migrating to RBP CONFIDENTIAL 73
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:

Migrating to Role-Based Permissions

74 CONFIDENTIAL Migrating to RBP
7 Testing Your Role-Based Permissions

After you have set up all groups and roles and granted the roles, you must 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 non-productive instance (e.g., sandbox,
development, test, or preview). Otherwise, roles which require dedicated groups cannot be tested. If the data is not
there to populate the granted users group or the target users group, the tests will fail. One approach is to update
the non-productive 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.

Another approach is to test roles that do not require specific groups, but which make use of relationships. In this
case, you need to test users for all hierarchy levels, such as Manager, HR Manager, and Employee. Next, check the
hierarchy, and log on as a specific test user and verify the permissions.

RBP Ad Hoc Reports [page 75]

Use ad hoc reports to understand an RBP configuration.

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

7.1.1 Enabling Ad Hoc Reports with Cloud Support

Ad hoc reporting can help you to understand your role-based permissions configuration.

Context

 Remember

As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP Cloud
Support.

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 75
Procedure

1. Log on to the Provisioning tool and go to Company Settings Additional Adhoc Sub domain Schemas
Configuration .

2. When ad hoc reports are enabled, go to Analytics Reporting Ad Hoc Reports . You can create the
following reports:
○ RBP User to Role Report
○ RBP Permission to User Report
○ RBP User to Group Report
○ Permission Roles Report

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

Migrating to Role-Based Permissions

76 CONFIDENTIAL Testing Your Role-Based Permissions
9. When the Permission Role Detail screen displays again, scroll to theGrant this role to section and search for the
granting group.
10. When the granting group displays, select Edit Granting
11. When the Grant this role to screen displays, select Super Admin as the granting group.
12. In the Target Group, select Everyone.
13. Click Done.
14. Click Save Changes to complete the process. Log out and log back into the system for your changes to reflect.

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

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 77
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.

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

Migrating to Role-Based Permissions

78 CONFIDENTIAL Testing Your Role-Based Permissions
7.2 Testing Your RBP Configuration

7.2.1 Using the Check Tool

Use the check tool to find potential problems and errors in your configuration before you call support about an
issue.

Prerequisites

Enable Metadata Framework (MDF). Most customers already use MDF.

Assign Access Check Tool and Allow Configuration Export to your role in Role Based Permissions (RBP).

● Access Check Tool authorizes users to access the tool.

● Allow Configuration Export authorizes users to attach configuration information to a ticket.

Procedure

1. Go to Admin Center.
2. In the tools search field, type Check Tool.
3. In Application, select the application you want to check.

 Tip

All Applications runs checks in all your applications.

For example, to run checks for Time Off, select Time Off.

You see the checks for the application you selected.

4. Click the check the box at top left in the table to run all checks.
5. If you want to run only some checks, select them individually.

 Tip

To understand what a check does, right click the Check ID. The system then displays some information on
the check.

6. Click Run Checks to check your applications for the checks you selected.

Next Steps

Evaluate the results and resolve the issues. If you encounter an error you cannot resolve, contact Support by
creating a ticket.

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 79
7.2.1.1 Check Results

After you run checks in the check tool, it returns the results of the check so that you can resolve issues that it
found.

To see the results of the checks, look in the Results column. If you run the checks multiple times to see how you are
resolving issues, look in the Previous Result column to compare the current results to previous results.

Possible Results of Check Tool

Result Action

No issues found If the tool cannot find issues, you see a green check mark the Result.

Issues found If the tool finds issues, it reports the number of issues and a yellow warning icon or a red alarm
icon.

● The yellow icon indicates a low severity issue. The system proposes a solution.
● The red icon indicates a high severity issue. You must take action, which could include creat­
ing a Support ticket.

7.2.1.2 Benefits of the Check Tool

The SAP SuccessFactors check tool helps you identify and resolve issues when your system doesn’t work as you
expect.

If your SAP SuccessFactors applications are behaving in unexpected ways, it is likely that it has a configuration or
data conflict: you have some data that is inconsistent or a configuration error. The check tool quickly identifies
these types of problems so that you can avoid support tickets. You might still need to create a support ticket if the
problem is severe, but even in severe cases, the check tool can save you time because it can export the results of
the check and your configuration for support. The support engineer, therefore, can identify the issue more quickly.

When you run the check tool, you see:

● A list of issues in your configuration or data and the severity of each issue.
● A solution or recommendation to address the issue.

7.2.1.3 Creating Support Tickets from the Check Tool

When the check tool reports a serious issue, you might need to contact Support. You can create a Support ticket
from within the check tool.

Prerequisites

Run the check tool. You can find the check tool by going to Admin Center Check Tool . You create the ticket
from the results page of the tool

Migrating to Role-Based Permissions

80 CONFIDENTIAL Testing Your Role-Based Permissions
Procedure

1. On the results page, look in the Result column for the errors you want to report on.

You usually contact Support for high severity issues not low severity issues.
2. Click the error in the result to open the Detailed Result.

 Note

If you cannot click the error, expand the list of checks from the Description column, and then click the error
from the Result column.

3. In Detailed Result Need Assistance? , copy the component ID.

For example, LOD-SF-EC is the component ID for Employee Central.

4. Create a customer incident in the relevant category.
5. When you create the ticket, paste the component ID into the ticket.

7.2.2 Does the Everyone Group Exist?

The CheckEveryoneGroup test validates that the Everyone group exists.

The Everyone group contains all employees in your system and is automatically created when RBP has been
enabled by your super admin. If the Everyone group has not been created in your system, you may experience
errors when attempting to create groups for other users in your system. The CheckEveryoneGroup test validates
that the Everyone group exists.

When you run this check, if the result is true, the Result section of the Check Tool displays the names of the User
Types that do not have the Everyone group. This may be either the Employee or External Learner user type.

Check ID Check Name Recommended Solution

CheckEveryoneGroup Verify if the Everyone Group Exists Since the Everyone group is created
when you enable RBP in your system,
disable RBP and enable RBP.

7.2.3 Do Roles Exist Without Groups or Users?

The CheckRoleRuleAccessGroupUser test validates if your system contains roles that exist without access
permission users or groups.

In your system, each role should contain access users or groups. When users or groups have not been assigned to
a role, run time exceptions may occur. These exceptions can occur anytime the system tries to execute access
permissions in your system.

When you run this check, if the result is true, the Result section of the Check Tool displays the names of the roles
that do not have access users or groups assigned to the role.

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 81
Check ID Check Name Recommended Solution

CheckRoleRuleAccessGroupUser Verify if Roles Exist that are not Associ­ Execute any of the following solutions if
ated with Access Permission Groups or you have errors in your system after run­
Users ning this check.

• Associate Permission groups or users

that you want to grant this permission
role to.

• Deactivate the rules that are not cur­

rently associated with any permission
groups or users.

• Delete any rules that are not associated

with permission groups or users.

7.2.4 Do Roles Exist Without Target Population?

The CheckRoleRuleTargetGroup test validates if there are any roles in your system where target population hasn't
been defined.

Roles in your system contain some permissions that require target population to be defined and other permissions
that do not require target groups. For permissions that require a target group, you must define a target group for
the role. When you don’t define a target group, you may experience errors in your system when the system
attempts to calculate target group permissions.

When you run this check, if the result is true, the Result section of the Check Tool displays the names of the roles
that do not have target groups assigned to the role.

Check ID Check Name Recommended Solution

CheckRoleRuleTargetGroup Verify if Roles Exist Without Target Popu­ Execute any of the proposed recommen­
lation Defined. dations below for the roles listed in Re­
sults section:

• Specify the target population for whom

granted users have permission to access.

• Deactivate the rules that are not cur­

rently associated with any target popula­
tion.

• Delete any rules that are not associated

with a target population.

Migrating to Role-Based Permissions

82 CONFIDENTIAL Testing Your Role-Based Permissions
7.2.5 Do Group Names Exceed 1000 Characters?

The CheckAccessGroupNameLength test validates if the total length of access group names that are associated
with a rule exceeds 1000 characters.

When you associate rules to your roles it’s important that you do not exceed 1000 characters for each rule. While a
rule can contain several groups and a role can contain several rules, each rule should not contain 1000 or more
group name characters. Meaning, the names of your groups, for each rule should not exceed 1000 characters.
Access groups with 1000 or more characters may cause errors or slow down your system.

When you run this check, if the result is true, the Result section of the Check Tool displays the names of the roles
that contain 1000 or more characters in total length.

Check ID Check Name Recommended Solution

CheckAccessGroupNameLength Verify if the Access Group Names Associ­ Execute any of the following solutions if
ated with a Rule Exceeds 1000 Charac­ you have errors in your system after run­
ters. ning this check.

• For each role in the Results section, re­

view the highlighted rules.

• Create a new access group that in­

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

• Replace the current access groups with

the newly created access group.

• You can also rename the associated ac­

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

7.2.5.1 What are Rules in RBP?

Rules in RBP are used to define access to permissions in your system.

Rules are defined by determining which permission roles you’ll assign to your groups or users. From the Permission
Role Detail screen in your system, each rule is represented by a row that contains your list of granted users or
groups and the associated target group. Depending on the complexity of the roles and access or target group
assignments, your roles could have various combinations of access and target group rules.

From your permission role detail screen, where you manage your permission roles, each row represents a rule and
each rule can have multiple access and target group associations, as detailed in the display.

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 83
7.2.6 Do Target Group Names Exceed 1000 Characters?

The CheckTargetGroupNameLength test validates if the total length of target group names that are associated with
a rule exceeds 1000 characters for a role.

When you associate rules to your roles it’s important that you do not exceed 1000 characters for each rule. While a
rule can contain several groups and a role can contain several rules, each rule should not contain 1000 characters
or more target group name characters. Meaning the names of your targer groups for each rule should not exceed
1000 characters. Target groups with 1000 or more characters may cause errors in your system.

When you run this check, if the result is true, the Result section of the Check Tool displays the names of the roles
that contain target group names with 1000 or more characters in total length.

Check ID Check Name Recommended Solution

CheckTargetGroupNameLength Verify if the target group names associ­ Execute following solution if you have er­
ated with a rule exceeds 1000 characters rors in your system after running this
check.

1. Create a new target group that includes

all the target groups associated with a
rule.

2. Or condense the current target groups

into fewer target groups.

3. Replace the current target groups with

the newly created target group.

You can also rename the associated tar­

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

Migrating to Role-Based Permissions

84 CONFIDENTIAL Testing Your Role-Based Permissions
7.2.7 Does a User Have the Same Permission More Than 30
Times?

The CheckUserPermissions test verifies if there are employees in your system who have been granted the same
permission more than 30 times.

When employees in your system are granted with the same permission multiple times by granting them roles that
contain duplicated permissions, it may cause your system some issues, such as system slowdowns or errors.

When you run this check, if the result is true, the Result section of the Check Tool displays the user names,
permission names, the number of times the user has been granted the permission, and the role names associated
with the permission. Additionally, by clicking the user names, you can review more records that are associated with
each user.

Check ID Check Name Recommended Solution

CheckUserPermissions Verify if a user has been granted the Execute any of the following solutions if
same permission more than 30 times you have errors in your system after run­
ning this check.

• Determine roles defining the Permis­

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

• For additional roles, work on an excep­

tion basis and include only the unique ex­
tra permissions that the role should have
beyond other roles.

• Avoid Duplication of permissions across

roles.

7.2.8 Does a Role Have More Than 100 Rules?

The CheckRulePerRole test validates if there are more than 100 rules associated with a role.

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

Migrating to Role-Based Permissions

Testing Your Role-Based Permissions CONFIDENTIAL 85
When you run this check, if the result is true, the Result section of the Check Tool displays role name and the
number of rules associated with the role.

Check ID Check Name Recommended Solution

CheckRulePerRole Verify if the number of rules associated Execute any of the following solutions if
with a role exceeds 100 you have errors in your system after run­
ning this check.

• Minimize the number of rules by com­

bining them into fewer rules and then re-
associate to the role.

• In case you have specific needs and you

are not able to combine the rules, split
them in different new permission roles
that do not exceeds 50.

7.2.8.1 What are Rules in RBP?

Rules in RBP are used to define access to permissions in your system.

Rules are defined by determining which permission roles you’ll assign to your groups or users. From the Permission
Role Detail screen in your system, each rule is represented by a row that contains your list of granted users or
groups and the associated target group. Depending on the complexity of the roles and access or target group
assignments, your roles could have various combinations of access and target group rules.

From your permission role detail screen, where you manage your permission roles, each row represents a rule and
each rule can have multiple access and target group associations, as detailed in the display.

Migrating to Role-Based Permissions

86 CONFIDENTIAL Testing Your Role-Based Permissions
8 Copying Configuration to the Production
Instance

After the tests are complete and all issues are resolved, you need to copy the RBP configuration to the production
instance.

Access the Instance Sync tool through the Admin Center. This tool allows RBP Roles and Groups to be copied
across data centers. If you do not see this in the Admin Center, an Incident ticket needs to be opened, to enable
Instance Sync.

 Note

Instance Sync does not support Static Permission Groups.

Note: The customer will provide one Username to SAP Cloud Support (CS). This Username will be added to the
Granted Group and is the Username that should be used when trying to access Instance Sync.

Instance Synchronization for Role-Based Permissions Groups and Roles

1. Grant the Required Permissions to Appropriate Users

1. Log on to the instance and choose Admin Center.
2. In Tool Search, search for: Manager Permission Roles. Then select the role that will be responsible for
syncing data between instances.
3. Under Permission Settings, click Permission Administrator Permissions Manage Instance
Synchronization .
The following data artifacts should be enabled: RBP Permission Groups & Roles, Picklists or MDF Picklists,
MDF Object Definition, MDF Rules and Data Model
4. Permission Groups.
5. Log out and log in again.

 Note

The permission must be enabled in the Source and Target instance for successful Instance Sync. In
addition, The Instance Sync Admin must exist in both Source and Target Instance.

2. Copy Roles and Groups:

1. Choose Admin Center Synchronize Instance Configurations .
The configuration sync wizard starts.
2. Select the instance that you want to copy the data to.
3. Follow the wizard to select the target instance, and the groups and roles to be copied.

Migrating to Role-Based Permissions

Copying Configuration to the Production Instance CONFIDENTIAL 87
 4. 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, the user does not exist in
the target instance.

5. If the test run was successful, then choose Run Sync Now to actually copy the groups and roles.
For more information about how to use these tools, please refer to the Instance Sync: Implementation and
Administration Guide.

Migrating to Role-Based Permissions

88 CONFIDENTIAL Copying Configuration to the Production Instance
  Note

If Instance Sync does not work properly, manual migration will be required.

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

8.2 Important Tips for Copying Roles

Here are a couple things to keep in mind when coping 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

Migrating to Role-Based Permissions

Copying Configuration to the Production Instance CONFIDENTIAL 89
9 Role-Based Permissions Configuration
Workbook

Use the configuration workbook to document your role-based permissions requirements.

The purpose of the Role-Based Permissions (RBP) workbook is to act as a Record of Configuration for RBP. (The
workbook is not meant to provide full information on all RBP features and functionalities.

During implementation and beyond, we strongly encourage you to record the actual configuration, along with your
decisions and changes, in the Notes section following each area in the RBP Configuration Workbook.

You can access the RBP Configuration Workbook at this link. RBP Configuration Workbook

This image represents an example of what it looks like to map legacy permissions to RBP:

Migrating to Role-Based Permissions

90 CONFIDENTIAL Role-Based Permissions Configuration Workbook
10 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 91]
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 92]

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

Migrating to Role-Based Permissions

Troubleshooting CONFIDENTIAL 91
6. To learn more about the roles, click the pop-up window icon next to any role name.

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

Migrating to Role-Based Permissions

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

10.3 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.
4. In the Selection session of the tool, enter Access Users. You can select at most 2 access users.

Migrating to Role-Based Permissions

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

Migrating to Role-Based Permissions

94 CONFIDENTIAL Troubleshooting
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

Migrating to Role-Based Permissions

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

10.4 Running the RBP Diagnosis Tool

The Role-Based Permissions (RBP) Diagnosis Tool generates a report, in one click, that highlights potential risks for
the specific RBP configuration settings in the test and production instances.

This tool is available once RBP functionality is enabled on the Provisioning screen. The tool's Run button is
displayed in this section of the provisioning screen and is not accessible by customers.

SAP Cloud Support (CS), Professional Services, or Implementation Partners can click the Run button to perform
back-end checks on the Role and Group configurations in the customer instance. Upon completion, the report
automatically opens in a new browser window. The information contained in the report can be shared among
internal SAP SuccessFactors teams to determine improvements to the RBP configuration settings.

 Remember

As a customer, you do not have access to Provisioning. To complete tasks in Provisioning, contact your
Implementation Partner. If you are no longer working with an Implementation Partner, contact SAP Cloud
Support.

This report contains three columns: Description, ResultSet, and Suggestion.

● Description: Report name for a specific type of back-end system RBP check.
● ResultSet: Counts and USERS_SYS_ID information gathered during the check. If this column is empty for a
row, then there are no particular concerns for this check. If the column has an entry in a row, then see the
suggestion notes.
● Suggestion: Hard coded suggestions with best practices for solving potential configuration errors.

Migrating to Role-Based Permissions

96 CONFIDENTIAL Troubleshooting
Migrating to Role-Based Permissions
Troubleshooting CONFIDENTIAL 97
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.

Migrating to Role-Based Permissions

98 CONFIDENTIAL Important Disclaimers and Legal Information
Migrating to Role-Based Permissions
Important Disclaimers and Legal Information CONFIDENTIAL 99
www.sap.com/contactsap

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

No part of this publication may be reproduced or transmitted in any form

or for any purpose without the express permission of SAP SE or an SAP
affiliate company. The information contained herein may be changed
without prior notice.

Some software products marketed by SAP SE and its distributors

contain proprietary software components of other software vendors.
National product specifications may vary.

These materials are provided by SAP SE or an SAP affiliate company for

informational purposes only, without representation or warranty of any
kind, and SAP or its affiliated companies shall not be liable for errors or
omissions with respect to the materials. The only warranties for SAP or
SAP affiliate company products and services are those that are set forth
in the express warranty statements accompanying such products and
services, if any. Nothing herein should be construed as constituting an
additional warranty.

SAP and other SAP products and services mentioned herein as well as
their respective logos are trademarks or registered trademarks of SAP
SE (or an SAP affiliate company) in Germany and other countries. All
other product and service names mentioned are the trademarks of their
respective companies.

Please see https://www.sap.com/about/legal/trademark.html for

additional trademark information and notices.

THE BEST RUN