SuccessFactors: all you need to know about Authorizations and Security

Data, security, and privacy are obviously quite important areas for customers in HCM and so I believe it is essential that customers understand how SuccessFactors protects their data through authorizations and security within the system. In this blog I will discuss the Role-Based Permission (RBP) framework in SuccessFactors that controls data access for different users. To understand how customer data is physically protected in the data center and during transfer to the web browser please refer to the Security in SuccessFactors section in the SAP and SuccessFactors – An Overview article published by SAPexperts and this blog by SuccessFactors’ Vinod Choudhary on How We Address Data Security in Europe and Canada.

About the RBP framework

The RBP framework is the authorizations framework used in SuccessFactors. Before I continue it is worth mentioning that there is a legacy permissions framework in SuccessFactors called Administrative Domains, which should not be used for new customers and is also not compatible with Employee Central v2. However, this may be used at some customers who have implemented SuccessFactors previously and those customers will need to transition to the RBP framework when they consider moving to some of the other HCM suite solutions.

The RBP framework allows for granular management of field-level permissions across most of the SuccessFactors HCM suite. It uses Permission Roles to be created that are assigned to Permission Groups (groups of users) for target populations (more on this later). This is not wholly different from the authorization concept in SAP. However, the RBP framework also includes structural-based permissions as standard (e.g. assignment of authorizations for a manager and 3 levels below). The RBP framework allows for granular rights at field-level, meaning that permissions (e.g. view, edit, correct, delete, etc.) can be controlled for each field in each role. Access to transactions and administrative functionality is also controlled to a fairly granular level. As an example, almost all fields, menu items, and actions in the Employee Files in Employee Central can be permissioned.

Access to Employee Self-Service (ESS) and Manager Self-Service (MSS) in Employee Central is configured using RBPs. The functionality for ESS and MSS transactions is built into Employee Central and permissions are used to control which users (i.e. employees and managers) can access which functionality (e.g. Personal Information view or Change Job Information transaction).

Caveats

There are a few minor caveats with RBPs that should be considered:

• Only one permissions framework can be used at one time: if a customer is using ADs for existing modules and one modules requires RBPs, then RBPs must be implemented for all existing modules
• Module-page permissions for Performance Management, Goal Management, Compensation, and CDP are controlled at the form level
• At present, RBPs only supports organizations with up to 300,000 employees
• SuccessFactors can slow down with bad RBP design (e.g. getting the same permission from different roles)

Concepts of the RBP framework.

The concepts of the RBP framework evolve around having Granted Users (who should have the permissions assigned) that have a Permission Role assigned (the permissions) for a Target population (those individuals that the permissions are applied upon). To summarize:

• Permission Role = group of permissions
• Granted Users = users that have the role assigned (and therefore the permissions)
• Target = population of users that are accessed using the permissions

This concept can be demonstrated in the diagram below:

A Permission Role can be re-used with different Granted Users and Target populations. A user can be assigned multiple Permission Roles. When a user has 2 different permissions they will get the most powerful of these permissions. For example, if a user is assigned an Edit permission and a View permission then they will get the Edit permission.

Permission Groups

Before we look into each of these core concepts, let’s take a brief look at Permission Groups. Permission Groups are simply groups of users that can be used as either Granted Users or Target populations. In each Permission Group various criteria can be used to select users, including but not limited to:

• City
• Country
• Department
• Division
• Geography
• Hire Date
• Job Code
• Location
• State
• Team View
• Time Zone
• Title
• User
• Username

Multiple different criteria can be used. Criteria can be combined (e.g. users in Department x with Job Code y) and multiple criteria can be used to select different types of users (e.g. users in Department x and users with Job Code y and users with Location z). Individuals can also be excluded from a Permission Group using the same criteria. Other fields and customer-specific fields can also be added to the list of criteria available in the system.

The screenshot below demonstrates a Permission Group called HR Group. This includes all users in the Talent Management Department and all users who are in the Enterprises Department and have Job Code Human Resources Manager. It excludes users who have Job Title of Recruiter, Recruiter – Brands, Recruiter – EMEA, Recruiter – HC, and Recruiter Software.

By clicking on the Update button in the Active Group Membership box the user can see the number of members of this Permission Group and by clicking on the number they can see a list of the users. The Granted Permission Roles tab shows which Permission Roles this Permission Group has been assigned to.

Now let’s look through the coreconcepts of the RBP framework.

Granted Users

Granted Users are those users that are assigned a Permission Role for a specific Target population. Granted Users can be one of the following options:

• A Permission Group
• Managers
• HR Managers
• Matrix Managers
• Custom Managers
• Second Managers
• Host or Home Managers (when on Global Assignment)
• Host or Home HR Managers (when on Global Assignment)
• Everyone

Granted Users – with exception of Permission Groups and Everyone – can be further filtered by a Permission Group. The options for the Target populations can vary depending on which type of Granted Users are selected for the Permission Role.

Target populations

Target populations are those users that Granted Users can access with the applied permissions in the Permission Role. If the Granted Users are a Permission Group or Everyone then the Target populations can be:

• Everyone
• Granted User’s Department
• Granted User’s Division
• Granted User’s Location
• Granted User

If the Granted Users are a type of Manager (e.g. Manager or Matrix Manager) then the Target populations can be:

• Granted User’s Direct Reports
• Granted User’s Direct Reports in a specific Permission Group

Additionally for Managers the level of indirect reports can be selected for 1, 2, 3, or all levels below and the manager themselves can also be included in this population.

Like with Granted Users, all of the Target populations – with exception of Permission Groups and Everyone – can be further filtered by a Permission Group. The Granted User can be excluded from the Target population if required. Generic Objects created in the Metadata Framework can have additional Target population permissions.

The screenshot below shows the options available for selecting Target populations when the Granted User is a Permission Group and the Target population is a Permission Group.

The screenshot below shows the options available for selecting Target populations when the Granted User is Managers and the Target population is Granted User’s Direct Reports.

Now let’s take a look at Permission Roles.

Permission Roles

Permission Roles are a group of permissions and are created by selecting the required permissions. This can either be selecting the type of action (e.g. view, edit, correct, delete, etc.) or selecting whether the user has access to a particular action or feature. Permissions are split into two main categories: User Permissions and Administrator Permissions. Within each of these categories are multiple other categories, such as Career Development Planning, Recruiting Permissions, and Succession Planners.

In the screenshot below the Employee Data permissions for non-Effective-dated employee data fields in Employee Central can be selected, either as View or Edit. Note that selecting an Edit permission automatically selects the View permission.

Effective-dated fields in Employee Central have additional permissions that can allow users to not only view and edit current data, but also to view the history and correct and delete records as necessary. Of course, different permissions can be given to different Roles so that, say, only HR Power Users can correct or delete Effective-dated employee data records. The screenshot below demonstrates these permissions.

Most other permissions are enabled or disabled via checkbox, as seen below for the Succession Planning permissions. The † sign indicates that the specific permission requires a Target population to be defined. Additionally, hovering the mouse cursor over the question mark icon next to a permission will display the help text for that permission.

Similarly, administrator permissions can be selected in a similar way:

Now that we’ve looked at the concepts of the RBP framework, let’s look at a couple of examples to demonstrate how these can be applied.

Example of RBP scenarios

Below are two examples of RBP scenarios. We will cover the process and assignment of Permission Roles, but we will not cover creating the Permission Roles themselves. The previous section should give some idea of how these can be created.

Example 1:

In this example we want all users in the USA with Job Code HR Professional to be able to create, edit, and delete any data in Employee Files for all employees located in the USA. Our requirement is:

• Granted Users = HR employees in the USA
• Permission Role = HR Administrator permissions
• Target population = Employees in the USA

This is demonstrated in the diagram below:

We will use the following steps:

1. Create 2 Permission Groups to use for our Granted Users and for our Target population:
   1. USA HR with criteria Country = USA and Job Code = HR Professional
   2. USA Employees with criteria Country = USA
2. Create a Permission Role called HR Role with all of the necessary permissions for a HR Administrator (e.g. maintain personal information or launch performance process)
3. Assign the HR Role Permission Role to:
   1. Granted Users: Permission Group USA HR
   2. Target population: Permission Group USA Employees

This final step is demonstrated in the screenshot below:

Once the Permission Role has been assigned to the Granter Users and Target population then the granting should be visible on the Permission Role, as seen below:

Now let’s look at another example, this time with managers.

Example 2:

In this example we want all users in the USA with Job Code HR Professional to be able to create, edit, and delete any data in Employee Files for all employees located in the USA.

In this example we want all managers in the USA to be able to launch the Change Job and Compensation Info action in Employee Files for all employees they manage directly and indirectly. Our requirement is:

• Granted Users = Managers in the USA
• Permission Role = Manager permissions
• Target population = Manager’s team and below

This is demonstrated in the diagram below:

Note that since we have already created a Permission Group for employees in the USA we don’t need to create any further Permission Groups in this example. We will use the following steps:

1. Create a Permission Role called Manager Role with all of the necessary permissions for a manager (e.g. launch the Change Job and Compensation Info action in Employee Files and have the relevant permission to view and edit data)
2. Assign the Manager Role Permission Role to:
   1. Granted Users: Managers in Permission Group USA Employees
   2. Target population: Granted User’s Direct Reports for All levels down

This final step is demonstrated in the screenshot below:

Again, once the Permission Role has been assigned to the Granter Users and Target population then the granting should be visible on the Permission Role:

Hopefully these two examples can demonstrate the way in which Permission Roles are assigned to users.

Granularity of permissions and Role Design

The RBP framework provides a great deal of granularity in assigning permissions and this can be a daunting task to design, create, and/or maintain. That is why it is very important to ensure that Permission Roles and the overall permission design is well thought out and catered for by a minimal number of Permission Roles.

To give an idea of the granularity of permissions, for Employee Central there are over 400 permissions that can be used in the various Permission Roles that would be required for end users and administrators. However, in comparison Succession & Development has only around 20 permissions and Employee Profile around 50 permissions – and permissions for both are largely view/hide options.

Reporting on Permissions

Each user’s permissions can be viewed in the system using the View User Permission transaction – if the required permission is assigned of course. This provides an overview of all permissions assigned to a user and from which Permission Role they have been granted through. This is a helpful tool for administrators when troubleshooting RBP issues for permissions and the right level of access.

In addition, there are four Ad-Hoc Reports provided for more detailed reporting on RBPs:

• RBP User to Role Report
• RBP Permission to User Report
• RBP User to Group Report
• RBP Permission Roles Report

Copying RBPs from one customer instance to another

RBP configuration can be copied from the Test instance to the Production instance. There are both Provisioning tools and a tool in OneAdmin. This requires activation prior to being permissioned to a user.

SuccessFactors Learning

The authorizations model in SuccessFactors Learning differs from the rest of the HCM suite in that it doesn’t leverage RBPs. To get a better understanding of how that works, I highly recommend Eric Wood’s blog SuccessFactors Learning Admin Security – Master of Your Domains?

Customer and Partner Resources

Customers and Partners can use the Role-Based Permissions Administrators’ Handbook to get more information on configuring and managing the RBP framework. Partners can also use the Role-Based Permissions Implementation Handbook to support implementation of RBPs.

Summary

The RBP framework differs from authorizations in SAP, but the design has similarities and for system administrators permissions should be much easier to maintain in-house than SAP authorizations are. The RBP framework is powerful, but also requires carefully planned design of Permission Roles. Handling assignment is fairly straightforward and can be managed and tracked easily. For Global organizations, the RBP framework makes the solution scalable and accessible with the required level of granularity. Overall this type of framework is good for customers and has enough flexibility to cater for most needs.