When it comes to IT systems that store sensitive information, access is a hot topic these days. An HR system like SAP SuccessFactors is no exception.
Based on my experience with access management and SuccessFactors, I would like to share some knowledge and a few opinions on how I think role-based permissions in SuccessFactors should be addressed. Through our experience, we have acquired best practices around the subject. Furthermore, my team has developed an SAP Cloud Platform Extension to automate the process and remove large parts of the operational maintenance task from central super administrators.
Happy reading.
Role-Based Permissions
Access management in SuccessFactors goes under the term Role-Based Permissions (RBP). RBP is a robust framework that allows key super administrators to configure and grant relevant access required for all your SuccessFactors users.
At the core of SuccessFactors role-based permissions are two elements:
- Groups: Users are defined either via a dynamic property such as a manager, country, or job code, or through a list of named users for those groups where no data point in your system can be used to easily identify a group.
- Roles: Roles are defined by a set of permissions required by one or more groups to perform their expected tasks in the system.
If a user has not been granted access, they cannot perform any action in the system. They won’t even be allowed to log in and see their own data. Nothing!
Once the data model is in place, the first step of any implementation is to define your basic access:
- Everyone: Basic permissions allow users to log in, see the org chart, see their peers, and perhaps even access the mobile app if your organization has matured to that stage.
- Employee Self-Service (ESS): ESS includes any action the users should be able to perform for themselves, including being able to see their own data.
- Manager Self-Service (MSS): MSS includes any action the users should be able to perform for their direct reports who are one or multiple levels down the org structure. MSS access also includes being able to see employment information.
An Extensive Framework
On top of these three roles are one or more HR and Admin accesses that your organization needs to define. The volume and complexity of these types of access depend largely on your organization’s size and geographical distribution, and how centralized or decentralized your organization operates.
The RBP framework is very extensive and is growing as SAP continues to expand the capabilities of SuccessFactors. To aid in the understanding of the settings, SAP has put a “List of Role-Based Permissions” describing the purpose of each setting in the framework on the SAP Help portal.
Best Practice Tips for SuccessFactors Role-Based Permissions
When defining your access model, keep these basic points in mind. I cannot count the amount of instances I have seen companies fail to follow one or more of the following:
- Don’t give the same access twice. This will reduce your system performance and make it more difficult to debug potential issues later. However, it may be required to give the same permission twice, if it is being granted for different target populations. For example, the ESS role grants access to base salary information to the employee, and the MSS role grants access to the manager to view for their direct reports.
- Reuse roles. If you have a local HR role, don’t create separate roles for each country; instead use the same role, but use different group granting to manage the access silos. Create add-on roles for local variations if required.
- Define a naming convention. Do this early in your implementation process; take future implementations into account and allow for flexibility. Stick to it. Some organizations reach a situation in which they have more than 50 roles. If the naming convention is not solid, it will make maintenance and debugging difficult later on.
- Keep your instances aligned. It is difficult to reproduce and find potential access-related root causes when the access rights in your test or development environment do not match your production environment. What is often perceived as a nuisance or waste of time is absolutely key to be able to resolve urgent issues rapidly and effectively down the line.
- Always keep your documentation up to date. In my experience, it is a sad fact that documentation is always an afterthought for most clients. It is a critical concern when we talk about access management. It should be the first step in a best practice governance model and should be done before updating anything in an instance.
How to Document
Documentation is key to properly manage your access definitions in SuccessFactors. I venture to say that if you only follow one of my best practice recommendations, consider this as the most important one.
It is true that you would be “okay” if you granted the same permissions multiple times and had duplicate roles and no naming convention, and all your instances had different configurations, as long as all this information was properly documented. Not great, but your system would be able to function. The system would work, your users would be able to perform their tasks in the system, and you could easily identify issues or areas of improvement/changes, if required.
That being said, how should you document your RBP configuration setup in SuccessFactors?
GP Strategies operates with two models. They are both viable, and we don’t prefer one over the other. The decision of which approach we use depends on the client’s maturity and the complexity of their SuccessFactors landscape. Personally, I don’t think there is a right or wrong here, and I am sure you can find other models out there. So, take this as inspiration or direct guidance. As long as you document somehow, you’re good to go.
Option 1 – Document your access configuration in the relevant module workbooks.
This option is recommended for smaller implementations with low complexity or few modules. Balance the effort required to document your environment with the resources available to you and your team, and do not make the documentation too scattered or cumbersome to find.
In each workbook, add columns that will capture the relevant permissions for each role. This gives you a simple, consolidated overview of the access configuration for each module.
Additional tabs will need to be added to capture permissions not directly related to a field/data point. I recommend storing some of the core configurations, such as group definitions and role granting, in your Employee Profile/Platform workbook.
Option 2 – Consolidate all your RBP configuration in a dedicated workbook.
I recommend that large organizations with full suite SuccessFactors implementations capture access configuration in a dedicated workbook.
The workbook should as a minimum contain:
- Role definitions: A matrix with all permissions available in SuccessFactors on the vertical axis and your access roles on the horizontal. Will this be a huge matrix? Yes, this matrix can easily reach the area of 5,000 to 10,000 cells.
- Group definitions: A list of all your groups and how they are defined, and if named users, the full and up-to-date list of users assigned to the group.
- Role mapping: A full overview of the group assignments of your roles in the system.
Your documentation can easily be extended to contain more information to make the document more readable for the consumer, for example, governance description, logic behind role design, etc.
This dedicated workbook allows you to quickly identify redundant roles, groups, and permission granting.
GDPR Consideration
It is not possible to talk access without talking GDPR, or data privacy and data protection. Many recommendations have been adjusted post GDPR, and new features have also been made available.
In my implementations prior to GDPR, my core message to clients was to keep it simple because the in-depth knowledge that any complexity added to the configuration short term would result in an end product that would be more time consuming to manage, enhance, and debug. Every extra role or group almost exponentially increases the workload in all these areas. Hence, if two HR roles were very similar in definition and only had minimal differences in access, I advocated to merge these roles.
Keeping it simple is no longer an option.
If clients are to be GDPR compliant, keeping it simple is not something I can recommend anymore. Access to personal data should be given only to users other than the owner if they have a valid need for this data. Ask yourself whether the role consumer would still be able to perform their job if they do not have this access.
For example:
- Do managers need to see the home address of their direct reports? Perhaps.
- Are there scenarios where this information would be informative or facilitating? Yes.
- Is seeing the home address a requirement for the manager to effectively manage their direct reports and relevant HR processes they are responsible for? I think not.
I have heard examples like having the need to be able to send flowers, in case of sickness or other events, to an employee’s home address. Undoubtedly, this is a nice gesture, but does it justify sharing employee personal data? The process can still be supported via HR without the manager gaining access to the employee’s personal data.
Providing access for a limited time range is now available.
Another dimension that is possible since Q1 2018 in Employee Central is the ability to delimit the time range in which access is granted.
So, let’s revisit the home address example and assume that we did find a valid reason to give access to the manager. Does the manager need to see the full historical record of the employee’s home address stored in the system dating 2, 5, or 10 years back? Or is access to the historical record for the last 6 months sufficient for the task required?
These are questions that need to be addressed during any implementation or revision of your access model in any IT system. Failure to do so will probably not have any direct consequences here and now, but there’s a future risk of an immense financial impact in the event of a data breach.
Even if the worst-case scenario never happens, you will have still built a more streamlined HR system in which users can focus on the information that they need to perform their tasks instead of being distracted by unnecessary information.
Beware of Pitfalls
As a rule of thumb, if the user is not granted an access, then they cannot perform the action or see the data. If the user is not granted login permission, then they cannot log in. If the user is not given access to Employee Files, then they cannot see any data on this tab, as they cannot access it.
There are, however, exceptions to the rule. Here are a couple of examples:
The biggest exception to the rule, by far, is in the area of the Metadata Framework (MDF). This is where data and configuration for many Employee Central sub-modules, such as Time On/Off and Global Benefits, are stored and available. MDF is becoming increasingly apparent in other modules, as well. There are hundreds of objects in MDF, so in order to browse through them, you need a permission to access the admin page, Manage Data, which is a good thing, as most of these objects are by default not permissioned.
Determining the proper permissions related to MDF objects is essential.
When working with permissions related to MDF objects, you need to think in reverse: Do we need to restrict this object? If we grant access to the object, do we need to restrict fields stored on this object?
The most common issue I have seen related to this is with the two standard objects, Country and Currency. The issue with these objects not being restricted by default is that users can edit these core objects via the MDF-based Payment Details block.
I have seen this happen a couple of times; an end user was “playing” around and changed the Country Code or Currency of a country, impacting key integrations that were relying on this data to be mapped correctly.
Giving permission to all MDF objects is unfortunately not a viable option, so you have to work closely together with a knowledgeable partner to identify and properly manage this and other similar pitfalls.
Understanding permissions can help ensure accurate access.
Another quirk appearing more and more in the RBP framework involves permissions that remove or restrict access. For example, in the Recruiting module, you can hide certain features from the solution via the RBP settings shown below. This can feel counter-intuitive and requires you to have a deeper understanding of the framework.
Who should manage the RBP configuration?
Every client needs at least one business owner to be the subject matter expert (SME) of the RBP configuration across modules for the entire SuccessFactors landscape. Potentially two or three SMEs should be assigned depending on client size and the number of SuccessFactors modules in scope. The task of this role is to understand the business access needs, review requested changes to role definitions, own the workbooks, and have, as a minimum, a high-level understanding of the data stored in SuccessFactors.
If they are technically capable and have the time to perform these actions, the SMEs in this role might be responsible for configuration changes in the system as well. Note that the SMEs do require a fairly high knowledge of SuccessFactors from a configuration standpoint. Gathering this knowledge requires substantial effort for large implementations. Therefore, in many cases, additional resources are made available to support with the actual configuration design and implementation according to the workbook definitions.
For security and privacy reasons, only a select few users should have access to modify the RBP configuration in your system, especially since access configuration is system wide and cannot be granted for only a portion of your user base. It is possible to configure different access models per country or legal entity, but it is not possible to grant the permission to modify these models for only parts of your system. Hence, the super administrators in your system who can access and modify your access models should be part of a central administration team that has the proper training and trust to handle the keys to your system.
Tip: You can now review which external users from implementation partners and SAP have access to your SuccessFactors back-end and have super administrator accounts. To see the list, go to your Admin Center and search for “Manage Provisioning Access.” Reviewing this list should be added as part of a recurring system audit process.
By default, it is difficult to decentralize the administration of access management in large or siloed organizations with the available standard functionality. This is not just related to changes to the access model, but also to changes in your organization. More than 50% of all RBP Group definitions are named users. In other words, if a person changes roles, or a team expands, a request to the access team is required. The request must be manually logged in the workbook and updated in the system. This ineffective process is hard to audit properly.
As a solution to this problem, our team at GP Strategies has custom built the extension Heimdall, based on the SAP Cloud Platform.
Enhanced Access Management with Heimdall
Heimdall is a custom solution and offering available only via GP Strategies.
Heimdall allows you to automate the access request-and-approval process for key roles that you cannot grant based on dynamic groups.
The solution is built and hosted on the SAP Cloud Platform (Read More Here) and is fully integrated with SuccessFactors. All access categories, requests, and audit trails are stored and managed in the MDF, meaning that no data is stored outside of your SuccessFactors environment, and you can report on the data with the Online Report Designer.
The Heimdall solution comes with a range of features to fully support your organization’s access administration:
- A simple access request configuration, including multi-step approval flows
- Notifications via mails or to-dos directly on approvers’ SuccessFactors home pages
- A pending requests overview page for users
- Admin reports to centrally monitor all pending requests
- The ability to be configured to support multiple languages
- An enhanced user experience, with SAP’s Fiori-based solution and Single Sign-On (SSO) with SuccessFactors
Heimdall has multiple clear benefits:
- Removes the time it takes for manual processing of access requests
- Reduces the need for super administrators with RBP configuration access
- Reduces the risk of human error and of users being added to the wrong group
- Provides a full system audit trail of all requests, including who approved them and when
If you would like to know more about Heimdall and how to better manage your SuccessFactors access setup, contact us or don’t hesitate to reach out to me directly.
About GP Strategies
GP Strategies SuccessFactors Practice has completed more than 650 SAP SuccessFactors projects in more than 80 countries worldwide during the last 15 years. We are covering all major industries, and we provide continued operational support and maintenance for more than 75 companies. GP Strategies is an SAP gold partner, and we have been awarded SAP Recognized Expertise in all SAP SuccessFactors areas. Together with our customers, we have won 13 SAP Quality Awards in 4 years. Contact us for expert guidance on any SuccessFactors subject.
About the Authors
