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).
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.
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:
- Hire Date
- Job Code
- Team View
- Time Zone
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 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
- 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)
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 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:
- 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 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.
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:
- Create 2 Permission Groups to use for our Granted Users and for our Target population:
- USA HR with criteria Country = USA and Job Code = HR Professional
- USA Employees with criteria Country = USA
- 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)
- Assign the HR Role Permission Role to:
- Granted Users: Permission Group USA HR
- 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.
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:
- 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)
- Assign the Manager Role Permission Role to:
- Granted Users: Managers in Permission Group USA Employees
- 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.
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.
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.
Great overview Luke.
Thanks again for the sharing and commitment to the community.
Wow !! This was some great information and insight into authorization world. Thanks Luke. I second what Rob Makinson said.
I wanted to understand how this works in a "Substitution" scenarios. Like SAP HCM is capable to managing selective approvals and structural authorization access for substitutes.
Thanks Sudhir! Substitutions are not handled right now, but I believe it's on the roadmap.
I wonder what customers end up doing in these scenarios. This is not a rare situation.. normally substition would be expcted of any approval process Prashanth Padmanabhan I should not be surprised through, even HR Renewal 1.0 FP4 .UI5 based Approval left Substitution for next release 😛
Sounds like a race between Employee Central and HR Renewal to get substitution functionality out first 😉
Hahaha... "unofficially" HR renewal 2.0 will bring Substitution in SAPUI5 services... so we are sorted.... EC.. your turn ;-)).
Luke, extremely precise and informative. I'll share it further.
Thanks Luke, great to get more of an insight of how security works in SF
Thanks for sharing your Knowledge. Very useful overview of the Authorisation and Security base on RBP.
I do like your examples from two different viewpoints, from where it prove how easily we can achieve a high degree of granularity.
Appreciate your time and effort.
This gives a fair idea about role based permissions and how authorizations are handled in Successfactors. A nice starter on this topic.
Many thanks for sharing,
Thanks for sharing a great document with clear examples....I have a small doubt here there are standard roles such as Employee,Manager , Matrix manager and HR Manager in SF. Is there is any difference between standard role and permission role???
What you are referring to are Workflow Roles. These are not the same as Permission Roles or Permission Groups.
Thanks very much for another fantastic blog and thank you for guiding us towards the right direction. We have just configured the basic permission groups and roles. But I am unable to creat the ad hoc report for RBP. As we are completely new to SF, I searched in SF Help & Tutorial: Ad Hoc Reports: Available Report List.
There are detailed instructions in RBP Administrator''s guide. But when I tried to create the report, define report: it only gave me Caliberation, Employee Profile, 360, Performance and Dev Goal, while in the guide, there seem to have 4 pages choices.. Is it because we haven't yet subscribed to Analytics? Are you able to shed some light?
Thanks a lot! =))
Another quesiton probably not relevant to this blog, for companise that are implementing both SAP HCM and SF at the the same time. What are your thoughts on the Nakisa embedded org chart vs SF org chart? How should companies send clear messages to employees so they are not confused where the source of truth lies and when they should look at which org chart. (Nightly Integration via PO). Should we always direct them to ESS/MSS for a structured view and recommend SF as a complement? The org box, its label fields and text fonts are fixed in Nakisa Embedded Org Chart, so a lot of employee names and positions are cut off. SF offers a much pleasant/flexible view, but it limits to one to one relationship. Any advice would be most welcome!
Sometimes not all the reports are given or Advanced EC reporting isn't enabled, etc. You should raise a Support ticket.
The embedded OrgChart is just for MSS transactions, so SuccessFactors should be the source of truth for employees. Managers should focus on the embedded OrgChart as it has a different purposes.
Great article Luke with clear instructions and pictures that gives us an insight into SF. This has cemented the fact that I can't wait to work on a SF project.
Thanks and good luck when you get your first project! 🙂
Informative and helpful article Luke and explained very well ..thanks !
Great blog as ever... 🙂
Got a S&A related qu that I haven't found an answer to... maybe you have the knowledge...
For large multi nationals user search can be problem. eg in sharing a CV or cascading goals... because there may be 10's of people with the same first & last name.
I know the userID is also provided in brackets... but this often doesn't help distinguish which is the correct 'Mark Smith' (msmith1), 'Mark Smith' (msmith2), 'Mark Smith' (msmith3), 'Mark Smith' (msmith4)... etc...
Are there settings to add the location and department to the user in the user search or is there the ability to restrict searches to local geographies/user role types/Divisions/Department for large implementations?
What applications are you using? The Talent Search or Directory are good places to start.
Specific example - Recruiting - sharing a candidate info with a colleague... we've got 40k people Australia & UK and want to roll out to EMEA and beyond...
In the Forward to field: start typing user's name the list of hits appears.
Mark Smith (msmith1)
Mark Smith (msmith2)
Mark Smith (msmith3)
Mark Smith (msmith4)
Mark Smith (msmith5)
It's impossible for the user forwarding the candidate to know at a glance which Mark Smith to send to... they would have to use the org chart to look up the userid.
Countless SF consultants and SF cust support confirmed this is working 'as designed'... but this is a design for SME org not large org... this piece of functionality essentially become unusable...
Potential solutions would be to:
- Add check boxes on the search to quickly filter by country, department, user type etc,
- Include location& department after the userID in brackets...
- User specific auto complete - ie prioritise the people used previously (ie the network of guys you normally interact with who are by far the most likely you want to pick from the list)
If any insights on whether this kind of update is on its way... or whether it's already possible but we just haven't found the answer yet... be great to hear.
Within Recruiting itself I don't know of a solution, but I'm not a product expert on SF Recruiting by any means. Brandon Toombs or Mark Ingram might be able to help.
Great document. Thanks for putting it altogether. I wanted to know a simple thing about this RBP but could not find a solution anywhere.
I had access to Manage Permission Group and Manage Permission Role, but due to some changes in the Role by myself while practicing in my Demo version, the menus are no more available in my instance. I mean the option of Manage Permission Group and Manage Permission Role itself is no longer there.
Question is how do I revert them back to that they start appear in my ADMIN CENTER. Please help.
You need to give your user permission to manage RBPs. This can only be done by a super user. If you don't have one, you can create a new one in Provisioning.
This is a great blog.
I have a One Question:
When create a Role group members and need to create 2 people pool for example :
(Department:Sales,Location:USA and the other people pool Department:IT,Location:UK)
and need to Exclude some people from each people pool how can determine which exclude people related to which granted people pool?
It doesn't necessarily matter which people pool they are excluded from, as long as they are excluded from the Permission Group.
Great contribution. Thanks
Request your help in RBPs.
I am currently working for a project where Employee profile is in scope and Employee Central is not in scope. we have a requirement where the user play three different roles in parallel.
for example: there are 4pple in a team.. A B C and D
the user play following roles
1. Team member Enzo in below screen shot: he/she should have complete access to their information.
2. Team mate role (Enzo) should have limited access to B information
3. TL team (Enzo) should have access to his team information B, C and D.
Yes, this is possible Godavari. Of course, it depends on how you identify those individuals outside of their team scope. There might need to be a role applied to the same group of granted users more than once but with different target populations to achieve this.
ok, I have set the permission group as below, not sure why team view is not working, can you please help on this Luke.
It's best to raise a discussion thread if you have a particular issue.
we are still using legacy permissions framework in SuccessFactors [Foundation + P&G] (called Administrative Domains) and we would like to transition to the RBP framework. Any documentation describing approach, hurdles etc... would be greatly appreciated.
There is nothing public-facing that I am aware of. The best bet is to reach out to an experienced partner who can help guide you through the process.
All the best,
How can we find Manage security -> Manage support access in RBP, new admin tool (admin center)
Hi Ahmed; I can't find it in NextGen admin either. But in the bottom left corner of the NextGen page, you can go back to OneAdmin. In OneAdmin, search the tools window and you will find it there.
I'm a long-time SAP security admin and new to SuccessFactors. I'm curious why SuccessFactors only allows SF professional services or SF partners to do most of the configuration in SF? Why should I have to depend on SF or a partner just to turn on and initially setup RBP? How do I as a customer find out what the Super User account is? Our HR department worked directly with SF and a partner to initially setup certain SF modules without involving anyone from the internal IT department and now they are asking for us to start supporting SF and we have no knowledge because they circumvented the process for bringing in new software products.
I am going through EC certification now. As such, I will say I have my theories as to why only SAP/SF or Partners are allowed to do some of the more "heavy lifting" but I will keep that to myself for now (haha). However, keeping up with SF over the past many quarters now, I have seen that they (SF) have moved more and more over from Provisioning and into the Admin Center (at least in EC). I think you will see more of this. However, I will also say that (1) config /set up takes much less time and doesn't need much "tuning" after....so a company really does not need to spend the money/time to get their resources up to speed. It is not like retaining on-prem knowledge. (2) there is quite a lot going on in config and dependencies and so forth that only an experienced person would know (they have not made a lot of it real easy) therefore, again, see #1....and as others have said MAKE SURE YOU USE QUALIFIED, CERTIFIED CONSULTANTS!......anyways, I think too that much of it is past perception with SAP on-prem.....a customer hears "workflow" or "security" mentioned with SF and imagine a very complicated system requiring lots of planning and resources and time and all they know from the SAP on-prem world....where, in reality, in SF, these are VERY easy, very basic (but powerful) systems. I plan to blog my "journey" to EC from the on-prem world on the "new" SCN and maybe that will help out to understand as well.
I think it's a misconception you have. Anyone who is qualified can do the configuration (and even unqualified sadly). I have worked on implementations where we trained the customer to perform configuration of the system and RBP was actually one of the areas that the customer configured. It's pretty straightforward to configure and I'm quite sad that HR chose to circumvent IT and also not have the partner give any knowledge transfer or training on managing the system 😯
How can I find out by Odata who is in my team?
You might have more luck if you post a question instead of a comment on a blog.
Do you know how large organisations manage Segregation of Duties risk/risk assessment when using RBP in SF ? With our on-premise SAP system everything is integrated with SAP GRC to check risks and then provision roles directly to SAP.
It seems that there is no standard integration to send RBP details for existing Users to GRC system so that new access requests can be risk assessed in GRC.
There is integration between EC and Access Control and a productized integration to GRC is becoming available soon. You can use AC to control access to EC as you would with on-premise. There are some details on the GRC AC integration here:
someone know if there is a way to create a permission group only for direct managers ?
You don't need to - you make that configuration on the permission role granting.
Hi Luke, We are in the middle of Successfactors implementation and coming across some challenges with role based permissions and segregation of duties. We are NOT challenging our employees to be on company domain (either logged on or via VPN). SFSF being in the public cloud, they will be able to logon to system from their personal computer at home our from anywhere outside the office.
There is no issue with individuals managing their information via self service portal. The main issue is with the administrators. Not only that they can manage their information but could also manage/troubleshoot/fix others as well. They logon in the same manner as a regular user but in their case they have elevated rights. If they loose their credentials or some how their credentials are stolen, these credentials could be used to access everybody's information under their provision.
Is there a way that, administrators could be restricted (systemically) to use VPN or challenged with an extra security questions (2 factor, or temporary code valid for short period of time, or ask for approval before accessing another employee's information).
Thanks for help in advance.
This challenge is no different from any other system, cloud or on-premise. You can introduce IP restrictions in Admin Center, but generally it is down to your users to protect their login credentials like they would their personal banking or any other system containing personally sensitive data.