RBP User Manual

Administration Guide PUBLIC
SuccessFactors Foundation
Document Version: Q3 2015 – August 7
Role-Based Permissions
Content
1 Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 What are role-based permissions?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Setting up Groups and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1 How do you create and manage permission groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Dynamic Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Static Permission Groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 How do you create a permission role?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Configuring a JAM Private Role to enable full search in Mobile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 How can you grant permission roles?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .18
Using Relationships to Grant Permissions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Specifying the Hierarchy Depth. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4 Granting Permissions for MDF Objects. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5 Further actions on permission groups. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.6 Further Actions on Permission Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 Troubleshooting. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.1 How can you check the permissions assigned to a user?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.2 How can you run an ad hoc report?. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3 How do you run a user search. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .30
PUBLIC Role-Based Permissions

2 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Content
1 Introduction
This content is intended for security administrators to enable them to manage Role-Based Permissions (RBP).
It is important to note that RBP is the only permission model that is available to new customers. New customers
cannot disable RBP to use legacy permissions. Existing customers, new companies of Professional Edition or free
trial are not affected.
The first section familiarizes you with the concept of role-based permissions.
The subsequent sections detail the individual tasks that make up the process. Finally, you will find troubleshooting
information in case problems occur with the permissions.
Note
This implementation content covers all general aspects of setting up RBP. The implementation handbooks for
the individual modules may contain additional module-specific information.
1.1 What are role-based permissions?
Role-Based Permissions (RBP) manage the permissions in the SuccessFactors suite. RBP controls access to the
applications and what users can see and edit. It's a suite-wide authorization concept which applies to the majority
of modules.
The main elements in RBP are permission groups and permission roles.
What are 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 would list all US-based employees
who work in the HR department. To define this group, you would specify that users must match the selection
criteria "Country = United States" and "Department = HR".
The attributes or selection criteria that are available for defining groups are configurable.
In RBP, you can assign permission roles to permission groups. In addition, you use groups to define the target
population a granted user has access to.
Role-Based Permissions PUBLIC

Introduction © 2015 SAP SE or an SAP affiliate company. All rights reserved. 3
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 dynamic, which means that the assignment of
employees into and out of a group is automated. For example, a group of granted users can be “All employees in
the Sales department”. As employees are transferred into and out of the sales department, their permissions will
automatically adjust. This automation will save you time and money. This is especially beneficial for large
organizations that need higher levels of administrative efficiency.
What are permission roles?
A role is a set of permissions. As such, a permission role controls the access rights an employee or group of
employees has to the application or employee data. 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 might be roles like "HR Compensation and Benefits Manager", "HR Manager for Sales", and "HR Learning
and Development Manager". While all three are HR managers, their roles have been distinctly carved out — one
handling compensation and benefits, another handling the sales team, and the third handling learning and
development.
Customers can have as many permission roles as their companies require.
How are groups and roles connected?
While roles define what is allowed, the groups define who is allowed to do it (granted users) and for whom (target
users). This graphic illustrates the principle:

4 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Introduction
Once a role is defined, you grant the role to one or more groups of users represented by the circles on the left.
Then you restrict the granted users to perform the role on target users. For example, you may decide that
managers (the left circle) can view dashboards (defined in the role) on their team (the right circle).
You can grant a role to many different user groups which in turn have different target user groups. Thus, you can
easily achieve a high degree of granularity.
Example
You could have a "Regional HR Administrator" role and use permission groups to make sure that US Admins
are limited to managing employees in the United States, while Europe Admins are limited to managing
employees in Europe, or AsiaPac Admins are limited to managing employees in AsiaPac. You would have only a
single role called "Regional HR Administrator" and would use groups to control access. Your groups would be
"AsiaPac Admins", "US Admins", "Europe Admins", "AsiaPac Employees", "US Employees", and "Europe
Employees".

Introduction © 2015 SAP SE or an SAP affiliate company. All rights reserved. 5
The role-based permission framework allows as many roles in the system as a company requires. At the same
time, each role can have a different level of permission granularity.
For detailed information about granting roles, see How can you grant permission roles? [page 18]
RBP Features
The features of RBP include:
● Administrator definable roles

● Automation of permissions assigned to users
● Definition of user access based on employee attributes, hierarchies and relationships, and exclusion rules
● Auditing of changes to security (who, what, when)
● Copy permission configuration between systems
Note
RBP is approved for organizations with up to 300,000 employees. We will continue to raise this bar in the
future. When in doubt, contact product management.

6 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Introduction
2 Setting up Groups and Roles
2.1 How do you create and manage permission groups
Procedure
1. Go to Administration Tools. In the Manage Employees portlet, select Set UserPermissions.

2. In the Set User Permissions section, select Manage Permission Groups.
The Manage Permission Groups page opens.

Setting up Groups and Roles © 2015 SAP SE or an SAP affiliate company. All rights reserved. 7
2.1.1 Dynamic Permission Groups
This is how you manage a dynamic permission group.
Procedure
1. Click the Create New button to create a new Permission Group.
The Permission Group page opens.

2. In the Group Name field, provide a name for your Permission Group.
3. In the Choose Group Members section, click the Pick a Category dropdown menu and select a category.
4. A search screen opens where you can either enter a search term or click magnifying glass, which will display
all values available.

8 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Setting up Groups and Roles
For some categories, a smaller pop-up window appears where you can enter values. The following screenshot
shows this window for the Time Zone.
If you select the "Team View" category, you can use hierarchical relationships to specify the group, as you can
see in this screenshot:
This allows you to apply rules such as "everybody in Carla Grant's team, all levels deep".

5. Make your selection and click Done.
6. 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
You want to create a group of sales employees working in the US. Then you choose the category
Department and select "Sales". You add a second category "Country" and select "USA".
7. Complex group definitions may require you to use multiple people pools. If you use two or more people pools,
this 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.
8. 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.
9. If you want to prevent the group being updated automatically when new employees match the selection
criteria, click Lock group.
10. Click Done to complete the process.
2.1.2 Static Permission Groups
Static permission groups store a static list of users instead of a list based on dynamic criteria. Changing user
information does not refresh group members. You can use static groups as RBP access groups or target groups.
.Currently you can do the following with static permission groups:

● View static permission groups and group members.
● Import static permission groups via CSV file. This can be either a full or replacement import.
Viewing Static Permission Groups
In Admin Tools go to Set User Permissions Manage Permission Groups
a A column indicates whether a group is dynamic or static.
Click the group name or click the button Take Action View summary to view a group detail.
Creating or Modifying a Static Permission Group
Full Replacement Import

1. Click the Import Static Groups button to create or modify static groups by uploading a static group data file.
2. From the popup window, click radio button "Full Replace" and then download a blank CSV template to see the
file format. The template has two column headers: GROUPNAME and USERID.
3. Add the static group name in GROUPNAME column and user IDs of users that belong to the static group to
the the USERID column. Please note the character encoding of the file should be Unicode(UTF-8). The
maximum file size is 20MB. If your import file exceeds 20MB, you can either split the file into several smaller

files or request Professional Service to modify the system configuration file.
4. Select the file with the data by clicking the Choose File… button. Click the "Full Replace" radio button. Click the
Validate File button to validate file format, file size, etc. If the validation is successful, click the Upload button
to import the static permission groups. The import process will be run as a background job. Please note that
for one group type a maximum of two jobs can be pending or running.
5. After importing complete, you will receive an email notification with success or error messages. A
successfully created group is then displayed in the group list upon refreshing.
Delta Replacement Import

1. Click the Import Static Groups button to create or modify static groups by uploading a static group data file.
2. From the popup window, click radio button "Delta Replace" and then download a blank CSV template to see
the file format. The template has two column headers: GROUPNAME and USERID.
3. Add the static group name in GROUPNAME column and user IDs of users that belong to the static group to
the the USERID column. Please note the character encoding of the file should be Unicode(UTF-8). The
maximum file size is 20MB. If your import file exceeds 20MB, you can either split the file into several smaller

files or request Professional Service to modify the system configuration file.
4. Select the file with the data by clicking the Choose File… button. Click the "Delta Replace" radio button. Click
the Validate File button to validate file format, file size, etc. If the validation is successful, click the Upload
button to import the static permission groups. The import process will be run as a background job. Please
note that for one group type a maximum of two jobs can be pending or running.
5. After importing complete, you will receive an email notification with success or error messages. A
successfully created group is then displayed in the group list upon refreshing.

2.2 How do you create a permission role?
Procedure
1. Go to Administration Tools.
2. In the Manage Employees portlet, select Set User Permissions.
3. In the Set User Permissions section, select Manage Permission Roles.
The Permission Role List page opens.

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

5. In the Role Name field, type a name describing of what the role allows you to do.
6. 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.
7. 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.

8. 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.
9. Select the checkboxes next to the permissions you'd like to grant to the role.
10. Click the Done button when you finish marking your selections.
11. In the Grant this role to section, click the Add button to select the employees to be granted this permission.

The Grant this role to page opens.
12. Grant the permissions and specify the target population according to what you have defined in the workbook.
For a detailed description, see the section How can you grant permission roles? [page 18]
13. 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.
14. Click the Done button to assign this role to the defined users. You are taken back to the Permission Role Detail
page.
15. Click the Save Changes button to complete creating the role.
Next Steps
Once this role is successfully created, the new role will be listed on the Permission Role List page.
2.2.1 Configuring a JAM Private Role to enable full search in

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

The system creates a default user search role if a company is RBP enabled when this feature is first rolled out to
maintain backward compatibility for user search.
2.3 How can you grant permission roles?
You can grant a permission role to everyone, or to a subset of employees determined by permission groups or
relationships.
● Permission groups: You assign a permission role to a defined group of users. However, relationships can also
play a role here as you can define that the granted user's managers have the same permissions. You can also
define how many levels up in the hierarchy you want this permission to be granted.

Note
If you allow the respective managers to have the same permissions, this may have a negative impact on the
performance. The hierarchy then has to be checked whenever such a manager tries to access an element
which was permissioned this way.
Note
If you want to grant a role to a named user, you first have to create a group and add the user to this group.
Then you can grant the role to the just created group.
● In the second case, you use relationships (for example, manager -employee relationship) 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 19].
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 each
permission it's indicated on the screen by a "t" whether it needs a target population. Target populations can also
be groups or can be derived from relationships.
2.3.1 Using Relationships to Grant Permissions
General Relationship Types
There are five relationships that can be specified through employee fields, and managed through tools like the
employee data. The five relationships are:
● Manager
● Second/Alternate Manager
● HR Manager

● Matrix Manager
● Custom Manager
Hierarchical relationships are characterized by a reporting line between the granted user and the target user.
These are relationships between employees and their managers, and employees and their second managers or
alternate managers.
Non-hierarchical relationships on the other hand are single-level relationships. These include the relationship of
an employee to the HR manager, the matrix manager and custom manager.
While each employee can have only one Manager, one Second Manager and one HR Manager, they can have
multiple Matrix Managers and Custom Managers.
Employee Central only: Relationship Types for Global Assignments
If employees have global assignments (that is, a job in another country), they have both a home manager and a
host manager. In addition, they have a home HR manager and a host HR manager. All managers need to have
access to both the home jobs of the employees as well as to the host jobs of the employees. This is covered by the
following additional relationship types for global assignments:
● Home Managers
● Home HR Managers
● Host Managers
● Host HR Managers
2.3.2 Specifying the Hierarchy Depth
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:
2.4 Granting Permissions for MDF Objects
You can grant permissions for viewing or editing generic objects which are part of the Meta Data Framework
(MDF). These objects, such as "Position", "Time", or "Absence", appear under Miscellaneous Permissions when
you create permission roles.

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

Example
You grant the permission to edit positions. As target population for this permission, you define the finance
department. The permissioned users are then allowed to change positions in the finance department only. If
you would choose All , the users could change all positions.
2.5 Further actions on permission groups
Context
You can edit, copy, or delete permission groups and also view a summary of a permission group and its change
history.

Note
You can only delete a permission group if no role is associated with it.
Procedure
1. Go to Administration Tools. In the Manage Employees portlet, select Set User Permissions.
2. In the Set User Permissions section, select Manage Permission Groups. The Manage Permission Groups page
opens.
3. Click Take Action next to the Permission Group you want to modify.
4. Choose the desired action.
Next Steps
2.6 Further Actions on Permission Roles
Context
You can edit, copy, or delete a role and also view a summary of a permission role and its change history.
Note
When copying a role, only the permissions get copied over. You will need to manually grant employees access
to this new role.

Procedure
1. Go to Administration Tools. In the Manage Employees portlet, select Set User Permissions.
2. In the Set User Permissions section, select Manage Permission Roles. The Permission Role List page opens
displaying a list of permission roles in the system.
3. Click the Take Action next to the role you'd like to work on.
4. Choose the desired action.
Next Steps

3 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 28]
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
29]
3.1 How can you check the permissions assigned to a user?
Procedure
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.

28 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Troubleshooting
6. To learn more about the roles, click the pop-up window icon next to any role name.
3.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.

Troubleshooting © 2015 SAP SE or an SAP affiliate company. All rights reserved. 29
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.
5. Click OK and then Generate Report.

6. In the report, you can now see exactly to which role(s) the permission is granted.
3.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 user or TBH user to be selected as Target User.
3. In the Set User Permissions section, select User Role Search.
4. In the Selection session of the tool, enter Access Users. You can select at most 2 access users.

5. Select Permission Category and one Permissions. If the permission needs target population, you can
optionally select one target user.
6. Click Search Roles Button. The search result will display all roles that grant this permission and target user to
the access users. If the target user field is empty, the search result will not consider target user.
7. On the Result session, you can click on the role name to see role detail. On the role detail page, the grant rules
that grant the selected access user and target user will be highlighted in the “Grant this role to …” session.

How can you compare permission roles?
You can use User Role Search to quickly search for an compare permission roles assigned to specified users in
role-based permissions.
3. In the Set User Permissions section, select User Role Search.
4. In the Selection session of the tool, enter the Access Users whose roles you are comparing.
5. Click Search Roles Button. The search result will display which roles, if any, grant the specified permission to
either user. In the following example, you can see that both of the selected access users have permission to
view address data.
6. If a user does not have the specified permission, it is indicated as "no result." In the following example, you
can see that the user "cgrant" has permission to view "Impact of Loss" data, due to her roles as a manager
and administrator. The user "jreed" is not assigned to any role that allows him to view this information.
7. You can also specify one target user, in order to see whether either of the two access users has the specified
permission for the specified target. In the following example, you can see that although both user "cgrant" and
user "dsharp" are managers, only user "cgrant" has permission to view "Impact of Loss" data for user
"vstokes". This is because, in this example, the manager role has a target permission group of "All Direct

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

Important Disclaimers and Legal Information
Coding Samples
Any software coding and/or code lines / strings ("Code") included in this documentation are only examples and are not intended to be used in a productive system
environment. The Code is only intended to better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, unless damages were caused by SAP
intentionally or by SAP's gross negligence.
Accessibility
The information contained in the SAP documentation represents SAP's current view of accessibility criteria as of the date of publication; it is in no way intended to be a
binding guideline on how to ensure accessibility of software products. SAP in particular disclaims any liability in relation to this document. This disclaimer, however, does
not apply in cases of wilful misconduct or gross negligence of SAP. Furthermore, this document does not result in any direct or indirect contractual obligations of SAP.
Gender-Neutral Language
As far as possible, SAP documentation is gender neutral. Depending on the context, the reader is addressed directly with "you", or a gender-neutral noun (such as "sales
person" or "working days") is used. If when referring to members of both sexes, however, the third-person singular cannot be avoided or a gender-neutral noun does not
exist, SAP reserves the right to use the masculine form of the noun and pronoun. This is to ensure that the documentation remains comprehensible.
Internet Hyperlinks
The SAP documentation may contain hyperlinks to the Internet. These hyperlinks are intended to serve as a hint about where to find related information. SAP does not
warrant the availability and correctness of this related information or the ability of this information to serve a particular purpose. SAP shall not be liable for any damages
caused by the use of related information unless damages have been caused by SAP's gross negligence or willful misconduct. All links are categorized for transparency
(see: http://help.sap.com/disclaimer).

34 © 2015 SAP SE or an SAP affiliate company. All rights reserved. Important Disclaimers and Legal Information
Important Disclaimers and Legal Information © 2015 SAP SE or an SAP affiliate company. All rights reserved. 35
www.sap.com/contactsap
© 2015 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 http://www.sap.com/corporate-en/legal/copyright/
index.epx for additional trademark information and notices.

RBP User Manual

Uploaded by

Copyright:

Available Formats

RBP User Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

RBP User Manual

Uploaded by

Copyright:

Available Formats

Administration Guide PUBLIC

2 Setting up Groups and Roles. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

PUBLIC Role-Based Permissions

1.1 What are role-based permissions?

What are permission groups?

Role-Based Permissions PUBLIC

What are permission roles?

Customers can have as many permission roles as their companies require.

How are groups and roles connected?

PUBLIC Role-Based Permissions

Role-Based Permissions PUBLIC

The features of RBP include:

● Administrator definable roles

PUBLIC Role-Based Permissions

2.1 How do you create and manage permission groups

1. Go to Administration Tools. In the Manage Employees portlet, select Set UserPermissions.

The Manage Permission Groups page opens.

Role-Based Permissions PUBLIC

This is how you manage a dynamic permission group.

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

The Permission Group page opens.

PUBLIC Role-Based Permissions

Role-Based Permissions PUBLIC

2.1.2 Static Permission Groups

.Currently you can do the following with static permission groups:

PUBLIC Role-Based Permissions

Viewing Static Permission Groups

In Admin Tools go to Set User Permissions Manage Permission Groups

a A column indicates whether a group is dynamic or static.

Creating or Modifying a Static Permission Group

Full Replacement Import

In Admin Tools go to Set User Permissions Manage Permission Groups

Role-Based Permissions PUBLIC

PUBLIC Role-Based Permissions

Delta Replacement Import

In Admin Tools go to Set User Permissions Manage Permission Groups

Role-Based Permissions PUBLIC

PUBLIC Role-Based Permissions

Role-Based Permissions PUBLIC

The Permission Role List page opens.

The Permission Role Detail page opens.

The Permission Settings window opens.

The list of permissions associated with this category is displayed.

PUBLIC Role-Based Permissions

2.2.1 Configuring a JAM Private Role to enable full search in

Role-Based Permissions PUBLIC

2.3 How can you grant permission roles?

PUBLIC Role-Based Permissions

2.3.1 Using Relationships to Grant Permissions

General Relationship Types

Role-Based Permissions PUBLIC

Employee Central only: Relationship Types for Global Assignments

2.3.2 Specifying the Hierarchy Depth

PUBLIC Role-Based Permissions

Role-Based Permissions PUBLIC

PUBLIC Role-Based Permissions

2.4 Granting Permissions for MDF Objects

Role-Based Permissions PUBLIC

PUBLIC Role-Based Permissions

2.5 Further actions on permission groups