10/27/24, 5:37 AM

Administering Onboarding 1.0

Generated on: 2024-10-27 05:37:15 GMT+0000

SAP SuccessFactors Onboarding | 2H 2024

PUBLIC

Original content: https://help.sap.com/docs/SAP_SUCCESSFACTORS_ONBOARDING/12be6a11886846cba1de18bf9027a0b6?

locale=en-US&state=PRODUCTION&version=2411

Warning

This document has been generated from the SAP Help Portal and is an incomplete version of the official SAP product
documentation. The information included in custom documentation may not reflect the arrangement of topics in the SAP Help
Portal, and may be missing important aspects and/or correlations to other topics. For this reason, it is not for productive use.

For more information, please visit the https://help.sap.com/docs/disclaimer.

This is custom documentation. For more information, please visit the SAP Help Portal 1
 10/27/24, 5:37 AM

Setting up Permissions
Configure Onboarding 1.0 and Role-Based Permissions to grant users access to different parts of the Onboarding 1.0 application.

To use Onboarding 1.0, you must configure permissions in both the Onboarding 1.0 application and SuccessFactors HCM Role-
Based Permissions. Once you have configured these two permission types, the user and permission syncs allow the two different
permission configuration to work together. Both Onboarding 1.0 and SAP SuccessFactors HCM have security groups and roles to
control permissions and user access.

 Note
Role Based Permissions are required for Onboarding 1.0.

Comparison of the authorization concepts in Onboarding 1.0 and SAP SuccessFactors HCM

Onboarding 1.0 SAP SuccessFactors HCM

There are ten fixed roles. Customers cannot add new custom roles. There are no predefined roles. Customers can create any number
of roles.

A role has specific access permissions, which define what parts A role has specific access permissions based on the system access
users who have this role can see and control. users have and the users they are allowed to see.

Groups of users are named individuals belonging to a group. Groups of users are named individuals assigned to a group based
on business logic or assigned individually.

A user can belong to more than one group. A user can belong to more than one group.

A group can be assigned to a one role only. A group can belong to more than one role

 Note
RBP Roles in SuccessFactors HCM must named identically to Onboarding 1.0 security groups. This includes case and spacing.
You cannot create additional Onboarding 1.0 Security Groups. Instead, create or updates RBP groups to correspond to the
Onboarding 1.0 groups.

Permissions in Onboarding 1.0 consist of three parts: Onboarding 1.0 groups, Onboarding 1.0 roles, and RBP roles:

Onboarding 1.0 groups are where Onboarding 1.0-specific permissions are set, for example which actions in Onboarding 1.0
a user has permissions for. Users are assigned to Onboarding 1.0 groups.

Onboarding 1.0 roles are assigned to an Onboarding 1.0 group. These roles determine what specific Onboarding 1.0 features
the group has access to. Each Onboarding 1.0 role can only be assigned one Onboarding 1.0 group. You cannot combine
distinct roles like Doc Center and Employee Portal. If you need a user to have the permissions of multiple roles, they must
be placed in multiple groups. Onboarding 1.0 roles are NOT adjustable or customizable

Roles in role-based permissions give general access to Onboarding 1.0 or other general features in SuccessFactors HCM.

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. Role-Based Permissions (RBP) applies to the
majority of SAP SuccessFactors products to restrict and grant user access to the products.

This is custom documentation. For more information, please visit the SAP Help Portal 2
 10/27/24, 5:37 AM

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 1,500,000 employees. When in doubt, contact Product 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.

Permission 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 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 need defined groups for roles that require a target population.

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/region, or job code. Permission groups can be
dynamic or static. Dynamic permission groups support employee and onboardee user types, while static permission
groups support only employee user type.
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.
Grant Permission Roles
This is custom documentation. For more information, please visit the SAP Help Portal 3
 10/27/24, 5:37 AM
You can assign a permission role to everyone or to a subset of employees, determined by permission groups, target
populations, or by relationships. When defining a role in RBP, you can assign the role to a group that you've created or you
can assign roles based on hierarchical relationships. Some roles will require that you also assign target populations, they're
only necessary for certain permissions in a role and your system will notify you when a target population is required.
What Are Rules in RBP?
Rules in RBP are used to define access to permissions in your system.

Related Information
Creating Dynamic Permission Groups
Creating Permission Roles
Assigning Roles to Groups

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/region, or job code. Permission groups can be dynamic or static.
Dynamic permission groups support employee and onboardee user types, while static permission groups support only employee
user type.

 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/Region = 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

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
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.
Managing Permission Groups

This is custom documentation. For more information, please visit the SAP Help Portal 4
 10/27/24, 5:37 AM
You can manage static or dynamic permission groups. You can also mark a permission group as RBP-only, which means the
group can be only used in Role-Based Permissions. If a permission group isn't RBP-only, it can also be used in other
modules, for example, on home page. For dynamic groups, you can also view the group's change history.

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.

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

This is custom documentation. For more information, please visit the SAP Help Portal 5
 10/27/24, 5:37 AM

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

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.

Adding Multiple Members to Static Groups

This is custom documentation. For more information, please visit the SAP Help Portal 6
 10/27/24, 5:37 AM
Instead of opening static groups one by one to add members, you can add multiple members to several static groups all at once
with a CSV file.

Procedure
1. Go to Admin Center Set User Permissions Manage Permission Groups .

2. Click Import Static Groups.

The Import Static Group popup displays.

3. Choose Delta Replace.

4. Click Download a blank CSV template.

A CSV template for delta replacement is downloaded.

5. Fill in the CSV file.

Column Head Description

GROUPNAME Fill in the names of the static groups that you want to add
members to.

USERID You can choose to provide either USERID or ASSIGNMENTID of

employees.

ASSIGNMENTID You can choose to provide either USERID or ASSIGNMENTID of

employees.

ACTION ADD

6. Save the file.

7. Go back to the Import Static Group popup and upload the CSV file that you’ve prepared.

8. Click Validate File.

A message displays at the top of the Import Static Group popup to inform you whether there’s any format issue in the CSV
file.

9. If there are no issues found in the validation phase, choose the CSV file again and click Upload.

10. Click Cancel to dismiss the Import Static Group popup.

Results
You have successfully added members to the static groups with a CSV file. You receive an email about the details.

Next Steps
Refresh the Manage Permission Groups page to double check the active membership of the static groups that you’ve updated.

Removing Members from Static Groups

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

Procedure
This is custom documentation. For more information, please visit the SAP Help Portal 7
 10/27/24, 5:37 AM
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 remove from the group.

4. Click Delete.

The list of users updates immediately.

5. Click Close.

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

Removing Multiple Members from Static Groups

Instead of opening static groups one by one to remove members, you can remove multiple members from several static groups all
at once with a CSV file.

Procedure
1. Go to Admin Center Set User Permissions Manage Permission Groups .

2. Click Import Static Groups.

The Import Static Group popup displays.

3. Choose Delta Replace.

4. Click Download a blank CSV template.

A CSV template for delta replacement is downloaded.

5. Fill in the CSV file.

Column Head Description

GROUPNAME Fill in the names of the static groups that you want to remove
members from.

USERID You can choose to provide either USERID or ASSIGNMENTID of

employees.

ASSIGNMENTID You can choose to provide either USERID or ASSIGNMENTID of

employees.

ACTION REMOVE

6. Save the file.

7. Go back to the Import Static Group popup and upload the CSV file that you’ve prepared.

8. Click Validate File.

A message displays at the top of the Import Static Group popup to inform you whether there’s any format issue in the CSV
file.

9. If there are no issues found in the validation phase, choose the CSV file again and click Upload.

This is custom documentation. For more information, please visit the SAP Help Portal 8
 10/27/24, 5:37 AM
10. Click Cancel to dismiss the Import Static Group popup.

Results
You have successfully removed members from the static groups with a CSV file. You receive an email about the details.

Next Steps
Refresh the Manage Permission Groups page to double check the active membership of the static groups that you’ve updated.

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

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

 Remember
As a customer, you don't have access to Provisioning. To complete tasks in Provisioning, contact your implementation
partner or Account Executive. For any non-implementation tasks, contact Product Support.

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

This is custom documentation. For more information, please visit the SAP Help Portal 9
 10/27/24, 5:37 AM
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.

 Note
When you search employees with the User category, the search results in the dropdown display only employee names.
When you search employees with the Team View category, the search results in the dropdown display employee names,
employee titles, and locations.

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/Region and select United States.

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

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

11. If you want to prevent the group being updated automatically when new employees match the selection criteria, click Lock
group.

12. (Optional) Choose Update in the Active Group Membership box to see how many users match the criteria. Click the
number to see the detail list.

The active group membership number isn't updated automatically when you modify the dynamic group definition.

13. Choose Done to complete the process.

Managing Permission Groups

You can manage static or dynamic permission groups. You can also mark a permission group as RBP-only, which means the group
can be only used in Role-Based Permissions. If a permission group isn't RBP-only, it can also be used in other modules, for
example, on home page. 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.

This is custom documentation. For more information, please visit the SAP Help Portal 10
 10/27/24, 5:37 AM

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.

You can see delete and view summary of static groups.

You can edit, copy, delete, view summary, and view change history of dynamic groups.

 Note
You can only see the most recent 1000 changes in the View change history view. If you want to see more than the
last 1000 changes, use the Change Audit report.

3. Choose the desired action.

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

Permission roles consist of a set of permissions that give employees access rights to an employee or a group of employees. As
such an employee or a group that has been granted with a permission role has access to certain aspects of the SAP
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

Permission roles can be created for employees and for external users, such as External Learning Users.
Assigning Permissions to a Role
After creating groups and roles, you'll need to assign permission roles to your employee groups.

This is custom documentation. For more information, please visit the SAP Help Portal 11
 10/27/24, 5:37 AM
Managing Permission Roles
You can edit, copy, or delete a permission role, view a summary of a permission role, and view its change history. You can
also mark a permission role as RBP-only.
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.

Creating Permission Roles

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

Context
Permission roles contain a group of permissions that can be granted to an employee or a group of employees known as the
Granted Users Circle. In general, its leading practice to define your user groups before defining your permission roles.

Procedure
1. Go to the Admin Center.

2. In the Tools Search field, select Manage Permission Roles.

3. To add a Permission Role, click the Create New button. The Permission Role Detail page opens.

4. In the Role Name field, type a name describing of what the role allows you to do.

5. In the Description field, provide a statement describing what the role allows an employee to do. Add a note about when the
role was created and by whom.

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

7. On the left side of the page, you see the different permission categories. Click a permission category to reveal the different
permissions.

The list of permissions associated with this category is displayed.

8. Select the checkboxes next to the permissions you'd like to grant to the role.

9. Click the Done button when you finish marking your selections.

This is custom documentation. For more information, please visit the SAP Help Portal 12
 10/27/24, 5:37 AM
10. In the Grant this role to section, click the Add button to select the employees to be granted this permission.

11. Grant the permissions and specify the target population according to what you have defined in the workbook. For a detailed
description, see the topic on granting permission roles in the Related Links section.

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

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

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

14. Click the Save Changes button to complete creating the role.

If you grant permissions to every employee when creating or updating a permission role, a double confirmation popup
displays when you save the changes.

Next Steps

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

Related Information
Grant Permission Roles

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.

This is custom documentation. For more information, please visit the SAP Help Portal 13
 10/27/24, 5:37 AM

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.

Managing Permission Roles

You can edit, copy, or delete a permission role, view a summary of a permission role, and view its change history. You can also mark
a permission role as RBP-only.

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

Procedure
1. Go to the Admin Center Tools Manage Permission Roles .

In the Permission Role List view, the following columns display.

ID. Permission role IDs are system-generated serial numbers according to the creation time of the permission roles.

Permission Role

User Type. The supported values are External Learner and External Onboarding User. If a role is an internal role,
there’s no value in the column.

Role Type. If it’s a Clock In Clock Out role, the value in the column would be Time Event. If it’s not a Clock In Clock
Out role, there’s no value in the column.

Description

This is custom documentation. For more information, please visit the SAP Help Portal 14
 10/27/24, 5:37 AM
Status

RBP-Only

Created From

Last Modified

Action

2. In the Permission Role List view, choose the Take Action dropdown menu next to the permission role you want to modify.

3. Choose the desired action.

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 user type External Onboarding 1.0 user. Permissions for the external user role can be
set to grant access to the Onboarding 1.0 home page.

Restoring the External User Password

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

Prerequisites

Either Onboarding 1.0 (including Internal Hire Process) or Learning or both must be enabled in Provisioning to reset the external
user password.

 Remember
As a customer, you don't have access to Provisioning. To complete tasks in Provisioning, contact your implementation partner
or Account Executive. For any non-implementation tasks, contact Product Support.

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

This is custom documentation. For more information, please visit the SAP Help Portal 15
 10/27/24, 5:37 AM
One exception is target populations. External users can be a unique target population. For example, if you want to manage external
users in Onboarding 1.0, you must add All(External Onboarding 1.0 User) to the target population of users managed by the
administrator.

Procedure
1. To reset an external user password, go to Admin Center Reset User Password .

The Resetting User Passwords page appears. From this page you can reset individual user password, or reset the
passwords for a group of users.

2. Select External Users from Onboarding 1.0 and/or Learning (If enabled) from the Find dropdown.

Enter the First Name, Last Name, or the Username to search for the user whose password you’re trying to reset. You can
filter your search further using Starts With or Exact Match.

3. When the user details appear on the screen, select the user and enter the new password in the New Password: field and
confirm the same in the Confirm Password: field.

4. Click Reset User Password.

Results

You have successfully reset the external user password.

Assigning Role Based Permissions to External Learners

Create a role mapping for external learners and grant them the permissions to log in to SAP SuccessFactors and access Learning.

Prerequisites
Role Based Permissions (RBP) must be enabled.

Enable External Learning User is selected in Provisioning.

 Remember
As a customer, you don't have access to Provisioning. To complete tasks in Provisioning, contact your implementation partner
or Account Executive. For any non-implementation tasks, contact Product Support.

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.

This is custom documentation. For more information, please visit the SAP Help Portal 16
 10/27/24, 5:37 AM
You can select additional permissions. For example, you can grant the external learners 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.

Next Steps
You grant admins permissions to manage external learners.

Grant Permission Roles

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

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

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

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

This is custom documentation. For more information, please visit the SAP Help Portal 17
 10/27/24, 5:37 AM

 Note
You can define a target population for external users through Manage Permission Roles Add For External Target
Population . 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 Relationships Between Managers and Employees.

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

Assigning Roles to Groups

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

Procedure
1. Go to the Admin Center.

This is custom documentation. For more information, please visit the SAP Help Portal 18
 10/27/24, 5:37 AM
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, choose Add.

 Note
If you have enabled Onboarding or Learning, you have an additional option Add For External Target Population where
you can restrict data access by defining external target populations.

5. When the Grant this role to screen displays, select Permission Group.

6. Click Select to select the access groups you wish to assign to this permission role.

You can allow managers to have the same permissions and define how many levels up in the hierarchy you want this
permission to be granted. However, allowing respective managers to have the same permissions may have a negative
impact on the performance. The hierarchy then has to be checked whenever such a manager tries to access an element
that 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’re 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.

Restricting Data Access of a Role with Target Population or

Criteria
You can restrict data access by defining target populations or criteria of roles that require tasks to be performed on behalf of
another employee.

This is custom documentation. For more information, please visit the SAP Help Portal 19
 10/27/24, 5:37 AM

Context

Target populations and criteria allow you to give employees such as managers and administrators access to data or tasks that
need to be maintained for other employees. 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’s no need to add a target
user group or target criteria.

For most of the permissions and secured MDF object definitions, you can restrict data access by either setting target population or
adding target criteria. For a few of the secured MDF object definitions, you can set its target population and further restricting the
target population with additional target criteria.

 Remember
Only object definition Employee Time can be configured with concurrent target population and target criteria.

You can identify permissions and object definitions that are available for target population configuration, in the Permission
settings screen, 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.

3. Select one of the permission roles you created.

 Note
As of the 2H 2022 release, you can configure target criteria for a permission role whose target population is external
users. If you have existing permission roles granted to groups whose target population is external users, review the
target criteria configurations of those roles. The target criteria configurations for said permission roles will stay as null if
you don't open and save the roles. When you open and save the roles, the target criteria configurations are set to all.

Please note that this feature isn't available for instances using Onboarding 1.0.

4. Choose Edit Granting for a role you’ve assigned this permission to in the Grant this role to section of the Permission Detail
screen.

5. Define target population in the second section of the Grant this role to... popup window.

To exclude the granted users from applying the permissions on themselves, select Exclude Granted User from having the
permission access to themselves.

6. Define target criteria in the third section of the Grant this role to... popup window.

 Note
Only secured MDF object definitions whose RBP Subject User Field is left empty are available for target criteria
configuration.

7. Click Done to assign this role to the defined users. You’re taken back to the Permission Role Detail page.

8. Click Save Changes to complete creating the role.

Relationships Between Managers and Employees

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

This is custom documentation. For more information, please visit the SAP Help Portal 20
 10/27/24, 5:37 AM
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/region), 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:

General Relationship Types Employee Central Only: Relationship Types for Global
Assignments

Manager Home Managers

Second/Alternate Manager Home HR Managers

HR Manager Host Managers

Matrix Manager Host HR Managers

Custom Manager

Managers (Internal Hire)

Delegate Relationship Assignments

As a delegator you can assign delegates to perform actions on your behalf that affects other employees in your organization.

As a manager, you can use the Delegate A and Delegate B relationship roles to assign permissions to up to two individuals for each
role, allowing them to act as your delegates. The delegate users you assign, can access your direct and indirect reports and can
perform tasks that have been permitted to you, while acting as your delegates. You can assign up to two delegates per delegate
role and each delegate can be given separate tasks or permissions to cover different functional or regional areas.

 Note
You must configure Delegate relationship type in the Employee Central Picklist. After you've configured your delegates, you'll
see the option to give permissions to this relationship type in your system. For more information about how to configure
picklists, see the topic Picklist Configuration for Employee Status and Job Relationship Type.

Why would I want to use delegates?

You might use a delegate when you want to assign delegates permissions in different functional areas.

You can also assign permissions to delegates that separate functionality according to locations.

If delegate relationship has been defined in Employee Central picklists, you can grant a permission role to delegates. When a
manager delegates his or her tasks to two delegates, delegate A and delegate B, the manager's direct reports are the target
population of delegate A and delegate B. If the manager, delegate A, and delegate B are in the same permission roles, delegate A
and delegate B will have the same permissions. The manager's direct reports are the target populations of the delegate A and
delegate B for the permissions that require a target. However, this delegate relationship can’t be used in non-user-based
permissions. For example, even if delegate A and delegate B has the same Miscellaneous Permissions Position permission

This is custom documentation. For more information, please visit the SAP Help Portal 21
 10/27/24, 5:37 AM
as the manager, delegate A and delegate B can’t view the current state of the position or view its history because the Position
permission isn’t user-based.

User-Based RBP Permissions Non-User-Based RBP Permissions

Description Permission to the data of a user. MDF objects that are categorized in the Permission
requiring MDF object target section.
The target population of the permission can be grouped as
a user list.

It can be RBP permissions or some of the MDF permissions.

Example The Personal Information permission controls access to The Miscellaneous Permissions Payment Information
the personal information data of a user. Detail permission.

Hierarchy Depth and User Permissions

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

This is custom documentation. For more information, please visit the SAP Help Portal 22
 10/27/24, 5:37 AM
When granting permissions using hierarchical relationships, you can specify how many levels down to go in the hierarchy for the
target population. For example, you can indicate that Managers can see performance ratings on their direct reports (1 level deep),
or allow it to go deeper into their team, that is 2 levels down or all levels.

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

For example, using the Matrix Manager relationship, you can use hierarchical depth to accomplish the following:

1 Level Deep: Matrix Managers can view ratings information for their Matrix Reports.

2 Levels Deep: Matrix Managers can view ratings information for their Matrix Reports and the Direct Reports of their Matrix
Reports.

All Levels Deep: Matrix Managers can view ratings information for their Matrix Reports (1 level deep) and the Direct Reports,
all levels deep of the manager hierarchy of their Matrix Reports.

The following graphic illustrates the different hierarchical depths you can specify when you use the Matrix Manager relationship:

This is custom documentation. For more information, please visit the SAP Help Portal 23
 10/27/24, 5:37 AM

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.

What are Onboarding 1.0 Roles?

An Onboarding 1.0 role is assigned to an Onboarding 1.0 group. There are ten role types that can be assigned. Each of these role
types refers to a specific responsibility within Onboarding 1.0. Administration users cannot create Roles. This task would be done
by the Professional Services Technical Team.

Roles with access to complete an entire process

Groups assigned to any of the following roles can perform any of steps in the new hire workflow (PostHire Verification, New
Employee, Orientation and Signature), monitor onboarding activities, and receive notifications to perform certain onboarding
tasks:

This is custom documentation. For more information, please visit the SAP Help Portal 24
 10/27/24, 5:37 AM
User

A User is someone who can onboard a new employee and monitor onboarding tasks. For example, an HR Generalist in the
corporate division can be assigned to onboard employees in a different division. A user group must have specific people
assigned to the group, similar to Windows™ security. Additionally, every person who has used Onboarding 1.0, including new
employees who have completed the onboarding process, can be found under the Users tab in the Security section.

Hiring Manager

A Hiring Manager is someone who can onboard a new employee, monitor onboarding, and receive notifications. The Hiring
Manager is a named user, meaning Onboarding 1.0 automatically assigns an activity based on the ID on the new hire record.
Group security can be setup so that an Onboarding 1.0 activity can be assigned based on the name of the Hiring Manager
that is included in the new employee record created by the ATS vendor, or entered in the PostHire Verification step.

 Note
By default, the PHV step is assigned to the Hiring Manager named user. To change this you must update the named user
options in Super Admin.

Recruiter

A Recruiter is someone who can onboard a new employee, monitor onboarding, and receive notifications. The Recruiter is a
named user, meaning Onboarding 1.0 automatically assigns an activity based on the ID in the new hire record. Group
security can be setup so that an Onboarding 1.0 activity can be assigned based on the name of the recruiter that is included
in the new employee record created by the ATS vendor, or entered in the PostHire Verification step.

Roles with access to complete an entire process have the following permissions:

Activity Permissions: Configurable permission to execute an activity under certain conditions, e.g., location, gender, age,
start date, etc.

Activity Steps Permissions: Configurable permission to execute any or all steps of a process.

Monitoring Permissions: Configurable permission to monitor an activity under certain conditions, for example, location,
gender, age, start date, etc.

Monitoring Steps Permissions: Configurable permission to monitor steps of a process.

Document Permission: Selectable permission to view documents from Work Queue.

Roles with access to complete certain assigned activities within a process

Groups assigned to perform one of the following roles can receive notifications to perform certain onboarding tasks. They cannot
perform any of the new hire steps.

Internal

Internal Resources are resources within the company that are assigned activities that need to be done in order to complete
the new employee’s Onboarding 1.0. For example, IT for technology provisioning, or Payroll for employee pay. Internal
resources cannot be assigned to execute new hire steps. They can only view activities assigned to them in their own Work
Queue; no hiring permissions are available.

External

External Resources are resources outside the company that are assigned activities that need to be done in order to
complete the activities needed to onboard a new employee, such as business cards and uniforms. External resources
cannot be assigned to execute new hire steps. They can only view activities assigned to them in their own Work Queue; no
hiring permissions are available.

This is custom documentation. For more information, please visit the SAP Help Portal 25
 10/27/24, 5:37 AM

Roles with access to the Document Center

Document Center

This role has permissions for viewing, saving, removing and uploading documents in the Document Center, as well as
viewing and/or updating indexes, viewing the document audit and re-indexing documents.

Roles with access to the Employee Portal

Employee Portal

The Employee Portal Group contains users with access to the Employee Portal administration.

Roles with access to administer the application

There are two types of administrator roles that can be assigned:

HR Admin

HR admins are responsible for maintaining the notifications, security, reference files, and certain account settings . This
role is typically reserved for customer administrators.

Partner Admin

Partner admins are responsible for managing the accounts, maintaining the notifications, security, and reference files that
govern the operations of Onboarding . This role is reserved for Onboarding 1.0 Principal Consultants and Professional
Services Partners.

Roles with access to configure Onboarding 1.0 settings

System Admin

The System Admin group contains users with access to manage Onboarding settings such as wizards, user controls, HR
Data, PDF forms properties, configuration settings. This role is reserved for SuccessFactors Engineering.

 Note
Do not manually add users to the System Admin group, and do not repurpose this group. If any users in the permission
sync are assigned to this group, the sync will fail.

Related Information
Named Users

What are Groups and Group Permissions?

Group permissions determine the actions available for a user within the application. By adding users to a specific group,
administrators can restrict the activities of different types of users on a per-application basis. Group membership controls who
can access Onboarding 1.0 and what actions can be performed.

For users responsible for onboarding processes, group permissions determine in whose queue an activity is placed. For example,
when a new hire is transferred from an Applicant Tracking System (ATS) to Onboarding 1.0, the new employee can be placed in the
Hiring Manager’s queue or an HR generalist’s queue.

This is custom documentation. For more information, please visit the SAP Help Portal 26
 10/27/24, 5:37 AM
For users responsible for administration of the site, permissions define the access to the administrative units. For example, an
administrator can have certain access to manage reference files, account settings and admin reports.

 Note
When configuring Advanced Conditions, make sure that you use valid data fields and values, especially when configuring
Advanced Conditions related to users. If an Advanced Condition is built with data that does not match the corporate structure
or other integrated data, the condition can break permissions.

How to Create a Group

Procedure
1. Go to Security Group and click Create.

2. In the Create Group window, enter the name of the group. The name can be any alpha-numeric word or words. For clarity
and ease of management, the group name should correspond to the group’s identity or function.

3. From the Role dropdown list, select a role type.

4. Select additional functions for users of this group:

Allow view glance

Allows users to view the data entered through the process steps.

Allow delete HRData

Allows users to delete an activity from the Work Queue.

Allow restart/edit steps

Allows users to restart or edit a step that has been completed. On the Onboarding 1.0 Dashboard, the user can click
an icon under Restart to restart the last completed step for a candidate. You cannot send users back to a previous
step, but can only restart the most recently completed step.

 Note
Step restart is not available for E-Verify processes.

Report Permissions

Allows users to create and view reports.

Reassign Activity

Allows users to re-assign an activity to any other user(s) from Work Queue.

5. If you do not need to assign permissions, click Create which completes the group creation.

If you need to assign Activity, Monitoring, or Document permissions, click Create and Assign and proceed as with the
following steps.

6. Click Select Process, then choose the process from the dropdown list. The available permissions are based on the selected
role and process.

a. Click Assign Activity Permissions.

b. Create the activity permission assignment formula based on the customer’s requirements:

Field: A field in the Onboarding 1.0 database.

Operator: The operator can be Equal or Not Equal to a certain condition value.

Condition Value: Any line containing alphanumeric or other symbols, by which the condition may be
activated.
This is custom documentation. For more information, please visit the SAP Help Portal 27
 10/27/24, 5:37 AM
c. Click Add.

d. If required, specify further fields and conditions and select the And or Or operator to link them to the previous.

If you want to edit a condition, select it in the list of conditions and click Edit. Edit the condition’s parameters and
click Add.

e. You can save the formula as a template by clicking Save as Template.

f. If the customer is using PJ codes (position/job codes) that need to be used for activity permissions, select Use
user’s PJ code.

g. If the configuration is complete, click Submit to save the changes and close the window. If additional configuration
is needed, click Apply Changes button to save the changes and keep the Assign Group window open.

7. To define the activity steps permission:

a. Select Activity Steps Permissions.

b. Select the workflow steps. The steps vary based on the process selected.

This is custom documentation. For more information, please visit the SAP Help Portal 28
 10/27/24, 5:37 AM

c. To save the changes and close the window, click Submit. To save the changes and keep the Assign Group window
open, click Apply Changes.

8. If you want the group to monitor the work queues of other groups, make the following settings:

a. Select WQ Monitoring Permissions.

b. Create the assignment formula based on the customer’s requirements:

Field: A field in the Onboarding 1.0 database.

Operator: The operator can be Equal or Not Equal to a certain condition value.

Condition Value: Any line containing alphanumeric or other symbols, by which the condition may be
activated.

c. Click Add.

d. If required, specify further fields and conditions and select the And or Or operator to link them to the previous.

In the example below, the group will be responsible only for new hires that are not in Company 2222.

This is custom documentation. For more information, please visit the SAP Help Portal 29
 10/27/24, 5:37 AM

e. You can save the formula as a template by clicking Save as Template.

f. If the customer is using PJ codes (position/job codes) that need to be used for activity permissions, select Use
user’s PJ code.

g. To save the changes and close the window, click Submit. To save the changes and keep the Assign Group window
open, click Apply Changes.

9. Define which work queue steps the group members will be allowed to monitor:

a. Select WQ Monitoring Step Permissions.

b. Select the work queue steps.

c. To save the changes and close the window, click Submit. To save the changes and keep the Assign Group window
open, click Apply Changes.

10. Determine if this group will have access to the documents in the Work Queue

a. Select Documents Permission.

b. Select the View Activity Documents checkbox.

c. Click Apply Changes.

11. When all permissions are assigned, click Submit.

Assigning Users to Groups

Once groups and users are established in Onboarding 1.0, users can be assigned to groups. Group assignment determines the
degree of access to Onboarding 1.0 appropriate to the user’s position and duties. In order for a user to have access to Onboarding
1.0, the user must be assigned to a group.

There is a nightly sync from SuccessFactors HCM to Onboarding 1.0 that will provide the user mapping for all roles, including the
Onboarding 1.0 permissions. Therefore, the Assign Groups to Users functionality is generally used to stage users for testing and
scripted demos, or to assign group permissions to external resources that will not have access to SuccessFactors HCM.

This is custom documentation. For more information, please visit the SAP Help Portal 30
 10/27/24, 5:37 AM

 Note
If you modify the permissions for a user in SuccessFactors HCM (as opposed to one created manually in Onboarding 1.0), the
changes will be overwritten by the nightly sync.

There are two ways to assign users to groups:

You can assign multiple users to one group using Assign Users to Groups

You can assign one user to multiple groups using Assign Groups to Users

How to Assign Multiple Users to a Group

Context

 Note
Tool: SuccessFactors Onboarding 1.0 Administration

Procedure
1. Under Security, select Assign Users to Groups.

2. Select the type of group and the group.

 Note
The roles Hiring Manager, Recruiter, and HR Manager are not included in the Select Type of Group dropdown list. You
can assign users to these groups only by checking the appropriate check box when you create a user.

All users assigned to the group will be displayed in the Assigned Users panel. All unassigned users will be displayed in the
Unassigned Users panel

3. On the Unassigned Users panel, select the appropriate users.

4. Click the arrow button to move them to the Assigned Users panel

To remove users from a group, select the users in the Assigned Users panel and then click the right-pointing arrow button
to remove the user from the group.

 Note
The permissions are changed immediately. There is no “save” function.

How to Assign an User to One or Multiple Groups

Context

 Note
This is custom documentation. For more information, please visit the SAP Help Portal 31
 10/27/24, 5:37 AM
Tool: SuccessFactors Onboarding 1.0 Administration

Procedure
1. Under Security, select Assign Groups to Users.

2. Enter the user name and users matching the criteria will be displayed. Select the desired user.

All groups assigned to the user will be displayed in the Assigned Groups list. All groups not assigned to the user will be
displayed in the Unassigned Groups list.

3. In the Unassigned Groups list, select the checkbox(es) next to the group name(s).

4. Click the left-pointing arrow button to move the groups to the Assigned Groups list.

To remove groups from a User’s security profile, select the checkbox(es) next to the Assigned Groups name(s) and then
click the right-pointing arrow button.

 Note
The permissions are changed immediately. There is no “save” function.

About Users
Under Security Users administrators can establish the Onboarding 1.0 List of Users and enter the attributes that describe
their user profiles.

The list of users displays the following information:

Login: Onboarding 1.0 User Name

 Note
You cannot use commas or other special characters in the Login field.

Last Name, First Name, Email: Identification and contact information

Creation Date: Date the user was created

Last Login Date: Last date the user was logged in to Onboarding 1.0

External ID: ID used to link user to an external system

Relations Number: Number of relations added to the user from the corporate structure

Is Locked Out: Login locked out status

The login is created automatically for new employees during the onboarding process and can be edited as needed.

Role-Based Permissions for Onboarding 1.0

This is custom documentation. For more information, please visit the SAP Help Portal 32
 10/27/24, 5:37 AM
To ensure a controlled access to different features of Onboarding 1.0, there are role based permissions. You can grant specific
permissions to roles and assign the roles to employees thereby permitting them to access the system as appropriate to their role.

Under User Permissions or Permission Location Permission Name Result

Administrator Permissions

Administrator Manage On/Offboarding 1.0 Manage Onboarding 1.0 Allows you to view the Onboarding 1.0 or
Permission On/Offboarding 1.0 tab in the main
SuccessFactors HCM menu. Also allows
access to the Onboarding 1.0 application
work queue.

Manage field mapping tool Allows you to access the Admin

for Employee Central Center Field Mapping tool for
Onboarding/Offboarding EC
Integration tool to define field
mappings for integrating
Onboarding/Offboarding with Employee
Central.

Manage Onboarding 1.0 Allows you to access the Configure new

additional content hire activity planning process, Maintain
Central Orientation Meetings, and
Maintain Lists of Items to Bring tools in
Admin Center.

User Recruiting Permissions Onboarding Initiate Allows you to initiate onboarding for a
Permission candidate in RCM. After onboarding is
successfully initiated, an onboarding
activity is created for the candidate in
Onboarding 1.0.

Onboarding Update Allows you to update the Onboarding 1.0

Permission activity for customers using Recruiting
Management - Verifications Inc.
integration.

 Note
This permission is not relevant for
SuccessFactors HCM Onboarding
1.0.

Administrator Manage Recruiting Manage Onboarding Allows you to add or edit Recruiting e-
Templates mail templates for Onboarding.

Setup Onboarding 1.0 Allows you to define field mappings for

Integration the RCM entity templates: Job
Requisition, Job Offer, and Job
Application. If you are using Intelligent
Services, you will get options for
propagating RCM updates to
Onboarding 1.0 and reassigning ongoing
Onboarding 1.0 activities.

Administrator Metadata Framework Configure Business Rules Allows you to configure business rules
related to MDF objects.

This is custom documentation. For more information, please visit the SAP Help Portal 33
 10/27/24, 5:37 AM

Under User Permissions or Permission Location Permission Name Result

Administrator Permissions

Administrator Metadata Framework Access to non-secured This permission, when enabled, allows
objects you to access the following non-secured
MDF entities:

OnboardingCentralMeetingEvent

OnboardingFirstDayItemList

OnboardingEquipmentType

OnboardingEquipmentTypeValue

OnboardingProcessConfig

 Note
If this permission is not enabled, the
above entities will not show any
content when you search for them in
Admin Center Manage Data
page.

User General User Permission (not User Login For more information about these
specific to Onboarding 1.0) permissions, see SAP SuccessFactors
Live Profile Access HCM Suite: List of Role Based
Permissions in the Related Information
SAP Jam Access
section.

Mobile Access

Related Information
SAP SuccessFactors HCM Suite: List of Role Based Permissions

Set up Permissions for Admin, HR, and Corporate Users

Context

 Note
The appropriate RBP groups or roles may already exist, particularly Hiring Manager and Recruiting roles for customers using
Recruiting. Discuss how to re-use the existing roles for Onboarding 1.0.

Procedure
1. Log on to SAP SuccessFactors HCM as an admin user.

2. Create the permission group:

a. Go to Admin Tools and in the Manage Employees block choose Set User Permissions Manage Permission
Groups .

b. Click Create New.

This is custom documentation. For more information, please visit the SAP Help Portal 34
 10/27/24, 5:37 AM
c. Enter a group name which describes the purpose of this group.

d. In the Choose Group Members section, click the Pick a Category dropdown menu and select User Name.

e. Select the admin, HR, and corporate users who need permissions for Onboarding 1.0 and click Done.

3. Create three permission roles and assign each to the group you have just created:

4. In the Manage Employees block, choose Set User Permission Manage Permission Roles .

5. Click Create New.

6. In the Role Name field, type a name describing of what the role allows you to do and enter a meaningful description in the
Description field.

 Note
When configuring permissions, the role name in SuccessFactors HCM must match the group name in legacy
Onboarding 1.0.

7. In the Permission Settings section, click Permission.

8. Select the permission:

For the first permission role, click Manage On/Offboarding 1.0 on the left, select Manage onboarding 1.0
permission and click Done.

Second permission role: Click Recruiting Permissions on the left, select Onboarding Initiate Permission and click
Done.

Third permission role: Click Manage Recruiting on the left, select Setup Onboarding 1.0 Integration, and click
Done.

9. In the Grant this role to section, click Add.

10. From the Grant role to drop-down list, select Permission Group and select the group you just have created.

11. Click Done and Save Changes.

Set up Permissions for New Hires

In production operation, as soon as the user import is complete, new hires are notified that users and credentials for logging into
Onboarding 1.0 have been created for them. To ensure new hires have access to a pre-start date Home page, you have to create a
new hire group and a new hire role.

Procedure
1. Log on to SuccessFactors HCM as a an admin user and choose Admin Tools.

2. Create the New Hire group:

a. In the Set User Permissions block, choose Manage Permission Groups.

b. Enter New Hires as group name.

c. Add conditions for the group membership in the Choose Group Membership section.

d. Under Active Group Membership, click Update to check that your new hires are members of the New Hires group.

e. To complete the process, click Done.

3. Create the New Hires role and grant it to the New Hires group:

a. In the Set User Permissions block, choose Manage Permission Roles.

b. Click Create New and enter New Hires as role name.

c. In the Permission Settings section, click Permission.

d. Under General User Permission, select User Login, Live Profile Access and Jam Access.

This is custom documentation. For more information, please visit the SAP Help Portal 35
 10/27/24, 5:37 AM
If you want to enable the use of the Onboarding 1.0 mobile app for new hires, in addition add one of the following
permissions:

Mobile To-Do List Access

Mobile Organization Chart Access

Mobile Touchbase Access

Mobile Goals Access

This ensures that the new hire can access the Mobile option under Options which is necessary to activate a mobile
device.

e. If customers have LMS integrated in their instance and want to provide a New Hire curriculum, select Learning and
then Learning Access Permission.

 Note
Demo systems: You should connect SF Onboarding 1.0 to a Learning/Jam/Recruiting/EC instance. If your
salesdemo instance is not integrated to Learning or Jam, your staged new hire will not see information in those
blocks when they start, and the hiring manager will not be able to select recommended Jam groups for the new
hire.

f. Click Done and then under Grant this role to, select Add.

g. From the Grant role to drop down list, select Permission Group.

h. Click Select and select New Hires from the list, then click Done.

i. Click Done again and click Save Changes.

User Creation
Onboarding 1.0 has two types of users - new hires and employees. Employees can be a hiring manager, HR administrator, or other
employee of the customer. New hires are users moving through the onboarding process. Once onboarding is complete, they
become employees.

Upload the User Import File to SuccessFactors HCM before any other processes can occur. This file contains all the data for
existing employees.

After uploading the User Import File and running the OnStartDate job (if the customer is not using Employee Central), configure
the User Sync report. Before running the User Sync report, permissions must be correctly configured for all users. When
configuring permissions, the role name in SuccessFactors HCM must match the group name in legacy Onboarding 1.0. The User
Sync report aligns user IDs between the SuccessFactors Onboarding 1.0 system and the legacy Onboarding 1.0 system.

New Hire User Creation Scenarios

With Recruiting Management and Employee Central•

User clicks the Initiate Onboarding button on the application

This automatically creates the Onboarding 1.0 record. The OnboardingCandidateInfo MDF object is created in in SAP
SuccessFactors HCM and associated with the candidate applicant ID.

After the corporate user completes the Post-Hire Verification step, and the New Employee Step is completed by the
new hire, the Paperwork Done notifications triggers Employee Central to pick up the new hire record.

The corporate user loads the Employee Central PreHire page, automatically triggering Employee Central to pull the
Onboarding 1.0 record.
This is custom documentation. For more information, please visit the SAP Help Portal 36
 10/27/24, 5:37 AM
The corporate user completes the Employee Central record, automatically creating the Employee Profile and
passing the Employee ID to Onboarding 1.0 and Recruiting Management. The OnboardingCandidateInfo object
updates to include the User ID (employee number).

 Recommendation
The OnStartDate job is not required for this scenario.

 Note
If a candidate is a former employee of the company, Employee Central compares the candidate's first name and last
name, and Social Security number, as well as date of birth or other parameters to the company's previous employees. If
there is a match, Employee Central sends the rehire's previous ID to Onboarding 1.0. Any old activities with a matching
user ID are deleted, and the new Onboarding 1.0 activity is updated with the user ID. Rehires do not require additional
configuration.

With Recruiting Management and a Third-Party HRIS

User clicks the Initiate Onboarding button on the application

This automatically creates the Onboarding 1.0 record and OnboardingCandidateInfo MDF object is created in SAP
SuccessFactors HCM, with the candidate an applicant ID.

The corporate user completes the Post-Hire Verification step, and the new hire completes the New Employee Step

Run the standard export, or wait for the scheduled standard export job to run. This sends the new hire record to the
HRIS and the HRIS record is completed. The HRIS does not need to send the employee number back to Onboarding
1.0. It should only be sent to SuccessFactors HCM via the user import/update file.

The HRIS sends the user import/update file nightly to SAP SuccessFactors HCM with all employees/users, including
the new hire records. This file is separate from the Onboarding file.

A new hire sees the home page tile immediately after creation of their Employee Profile inSAP SuccessFactors HCM
via the update file. There is no permission or flag corresponding to the ability to view the home page tiles.

If you would like new hires to have pre-state date access, you can set the IsOnboardingUser flag for only new
hires in the user update file, and use role-based permissions to define a group of users with limited access to the
system. Inclusion in this group can be driven by the flag.

You can also allow the user to see whatever is available pre-day 1 automatically.

Schedule and run the OnStartDate job before the User Sync. This job updates the OnboardingCandidateInfor object
with the UserID.

With Third-Party ATS and HRIS (Stand alone Onboarding)

The ATS sends the new hire file to Onboarding via the standard import.

 Recommendation
The Standard New Hire Import can be set up in one of two ways. If the customer is sending an HRXML formatted
file, it can be passed to Onboarding 1.0 using the Onboarding 1.0 Web Services. This requires setup of the web
services on the customer side. If the customer is not using an HRXML formatted file, navigate to Super Admin
Import/Export Settings Integration HRXML.ImportNewHire Download the .xlt file and perform a
transformation so the file can be submitted in an HRXML format. Then use the Onboarding 1.0 WebServices to
pass the file to Onboarding 1.0. The standard new hire import cannot be encrypted. Encrypting the import
requires a custom integration.

This is custom documentation. For more information, please visit the SAP Help Portal 37
 10/27/24, 5:37 AM
Once the new hire file is sent to Onboarding 1.0, the new hire record is created, and a candidate create notification is
triggered in SAP SuccessFactors HCM, creating the OnboardingCandidateInfo MDF object. Completing the first
panel of the PHV step triggers the candidate create notification. The candidates create notification and
OnboardingCanddiateInfo object are also created if the user is created via the Onboarding 1.0 Process tab.

The corporate user completes the Post-Hire Verification step, and the new hire completes the New Employee Step

Run the standard export, or wait for the scheduled standard export job to run. This sends the new hire record to the
HRIS and the HRIS record is completed. The HRIS does not need to send the employee number back to Onboarding
1.0. It should only be sent to SuccessFactors HCM via the user import/update file.

The HRIS sends the user import/update file nightly to SAP SuccessFactors HCM with all employees/users, including
the new hire records. This file is separate from the Onboarding 1.0 file.

A new hire sees the home page tile immediately after creation of their Employee Profile in SAP SuccessFactors HCM
via the update file. There is no permission or flag corresponding to the ability to view the home page tiles.

If you would like new hires to have pre-state date access, you can set the IsOnboardingUser flag for only new
hires in the user update file, and use role-based permissions to define a group of users with limited access to the
system. Inclusion in this group can be driven by the flag.

You can also allow the user to see whatever is available pre-day 1 automatically.

Schedule and run the OnStartDate job before the User Sync. This job updates the OnboardingCandidateInfor object
with the UserID.

About User Sync

User Sync reports are required to configure Onboarding 1.0. The User Sync report must run and complete before beginning the
Permission Sync report.

 Note
After February 2015, best practice is to use the Delta User Sync report to sync users to Onboarding 1.0.

As user data pass through the system, the label of the user ID changes. The following diagram illustrates those changes.

This is custom documentation. For more information, please visit the SAP Help Portal 38
 10/27/24, 5:37 AM

There are three different unique data ID keys:

Recruiting ID or Client ID - Unique number generated by the recruiting system or ATS to identify the new hire

HRData ID – Unique number generated by Onboarding 1.0 to identify the new hire activity

Employee ID – Unique number generated by Employee Central or the client's HRIS to identify the new employee

How to Create a User Sync Report

It is best practice to configure the Delta User Sync job rather than a User Sync Report.

Context

User Sync helps to sync the data between different applications in the SAP SuccessFactors Application Suite and Onboarding 1.0.
All the data selected as columns for individual users are synced.

This help in seamless SSO when users navigate from different applications in the SAP SuccessFactors Application Suite to
Onboarding 1.0.

 Note
It is important that the user with the same Username already exists in Onboarding 1.0.

Ensure that the users are already synced prior to the offboarding process.

Every time the list of users from different applications in the SAP SuccessFactors Application Suite are handed over to the
Onboarding 1.0 process using a .CSV file.

 Tip

This is custom documentation. For more information, please visit the SAP Help Portal 39
 10/27/24, 5:37 AM
It is recommended that you run User Sync once in a week, or once in a month, but run the Delta Sync daily.

Procedure
1. Log on to Onboarding 1.0 as an admin user.

2. Go to Analytics Reporting Ad Hoc Reports .

3. Click Create New Report.

4. Under Report Definition Type, select Employee Profile. Click Create.

5. On the General Info tab, enter a meaningful name such as 'User Sync' or 'ONBOARDING-UserSync'.

6. On the People tab, click Refine Criteria, select Other Filters under Team Reporting Type, enable Include inactive users and
click OK.

7. On the Columns tab, click Select Columns.

8. Select the following columns:

From Employee Information, select:

User SysID

First Name

Middle Name

Last Name

E-Mail

Hire Date

Division

Department

Location

Country

Status

Person ID External

Per Person UUID

From the Manager Information list, select 'Manager User Sys ID'.

From the HR Manager Information list, select 'HR Manager User Sys ID'.

9. Click Finished and then Save.

10. Click Generate to create the report, and check that all employees including the new hires appear in the User Sync report.

This is custom documentation. For more information, please visit the SAP Help Portal 40