How to Manage Access in SAP SuccessFactors

When it comes to IT systems that store sensitive information, access is a hot topic. An HR system like SAP SuccessFactors is no exception.

Based on our experience with access management and SuccessFactors, we’d like to share some knowledge (and a few opinions!) on how we think role-based permissions in SuccessFactors should be addressed. Through our experience, we’ve acquired best practices around the subject. Furthermore, our team has developed an SAP CI Extension to automate the process and remove large parts of the operational maintenance task from central super administrators.

Role-Based Permissions Basics

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 to all their 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. If no data point in your system can be used to easily identify a group, a list of named users can be employed

Roles: 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 choose your basic access roles. The main roles include:

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 one or multiple levels down the organization structure. MSS access also includes being able to see employment information.

An Extensive Framework

On top of these three basic access 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 to what extent your organization operates on a centralized or decentralized basis.

The RBP framework is extensive and is growing as SAP continues to expand the capabilities of SuccessFactors. To aid in the understanding of the settings, SAP has created a list of role-based permissions describing the purpose of each set 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. The Effective People team has encountered a high number of instances where 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 access twice if it’s 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 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 groups to manage access to different regional silos. Create add-on roles for local variations if required.

Define a naming convention. Do this early in your implementation process and take future implementations into account. Stick to the convention. Some organizations reach a situation in which they have more than 50 roles. If the naming convention isn’t solid, it will make maintenance and debugging difficult later on.

Keep your instances aligned. It’s 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 being able to resolve urgent issues rapidly and effectively down the line.

Always keep your documentation up to date. For some clients, documentation is always an afterthought. However, it’s a critical concern for access management. Documentation should be the first step in a best-practice governance model and should be done before updating anything in an instance.

2 Ways to Document Your Role-Based Permissions

If you follow only one of the best practice recommendations above, make it “always keep your documentation up to date". Documentation is key to properly managing your access definitions in SuccessFactors. Indeed, you can almost get away with ignoring the other recommendations if you document everything—though obviously, this isn’t our recommendation!

That being said, how should you document your RBP configuration setup in SuccessFactors?

Effective People operates with two models. Both are viable, and one approach isn’t preferred over the other. The decision of which approach we use depends on the client’s needs and the complexity of their SuccessFactors implementation. Whatever approach you choose, as long as you document everything somehow, you’re good to go!

Option 1: Document Your Access Configuration in the Relevant Module Workbooks.

This option is recommended for smaller implementations involving 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 dispersed 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. We 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 Configurations in a Single Dedicated Workbook.

Large organizations with full-suite SuccessFactors implementations may find it more effective to capture access configurations in a single dedicated workbook.

The workbook should as a minimum contain:

Role definitions: A matrix with all permissions available in SuccessFactors on the vertical axis, against access roles on the horizontal. Be aware that this matrix can easily reach in the region of 5,000 to 10,000 cells.

Group definitions: A list of all your groups and how they’re defined. Where named users are manually added without the use of dynamic properties, the full and up-to-date list of such users should also be available.

Role mapping: A full overview of the group assignments of your roles in the system.

Your documentation can easily be extended to contain additional, audience-relevant information. This could include, for example, governance description, the logic behind your role design, and so on.

One advantage of this dedicated workbook approach is that it will allow you to quickly identify redundant roles, groups, and permission granting.

GDPR Consideration: Simple Is No Longer an Option

It’s impossible to talk about access without talking about GDPR, data privacy, and data protection, and there’s no shortage of recommendations and new features that have arrived to address the regulations.

If clients are to be GDPR compliant, keeping it simple is no longer realistic. Access to personal data should be given only to users other than the owner if they have a valid need for this data. Whenever an access decision is being considered, you must consider whether access is absolutely essential for the task at hand.

For example:

Do managers need to see the home addresses 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’re responsible for? Almost certainly no.

Remember that you can still support processes via information available to HR. For example, if an employee welcomes a new child, the team may want to send flowers or a gift—while there’s no justification here for sharing an employee’s personal data with team members, the gift should be easy to organize via HR.

It’s Now Possible to Provide Access to a Limited Time Range in SuccessFactors Employee Central

Since Q1 2018, Employee Central has offered the ability to delimit the time range to 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 two, five, or 10 years back? Or is access to the historical record for the last six 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 carries a future risk of an immense financial impact in the event of a data breach.

Even if the worst-case scenario never happens, you’ll 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! A Deeper Dive Into Some Common Pitfalls

As a rule of thumb, if the user isn’t granted access, then they cannot perform the action or see the data. If the user isn’t granted login permission, then they cannot log in. If the user isn’t given access to the employee files tab, then they cannot see any data within it, as they cannot access it.

There are, however, exceptions to the rule. The biggest by far, is in the “Metadata Framework (MDF)” area of Employee Central. 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 integrated in other modules, as well. There are hundreds of objects in MDF, so in order to browse through them, you need permission to access the “Manage Data” admin page. This requirement is ultimately a good thing, as most of these objects are by default, not by permission.

Why Determining the Proper MDF Object Permissions Is Essential.

When working with MDF object permissions, 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?

One of the most common issues in this area occurs 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. This means that if a user “plays around” with these settings, they can potentially impact key integrations relying on the data to be mapped correctly—not good.

Giving permission to all MDF objects is unfortunately not a viable option. The best countermeasure available is to work closely together with a knowledgeable partner to identify and properly manage and account for this and other similar quirks.

Understanding Permissions Can Help Ensure Accurate Access.

Another quirk of 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. 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 key stakeholder to act as a 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’s 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’re technically proficient 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 level of SuccessFactors knowledge from a configuration standpoint. Gathering this knowledge requires substantial effort for large implementations. Therefore, in many cases, additional resources are made available to support the actual configuration design and implementation according to the workbook definitions.

For security and privacy reasons, only a select few users should have the ability to modify the RBP configuration in your system, especially since access configuration is system-wide and cannot be granted to only a portion of your user base. It’s possible to configure different access models per country or legal entity, but it isn’t possible to grant permission to modify these models on specific 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.” A review of this list should be added to your recurring system audit process.

By default, it’s difficult to decentralize the administration of access management in large or siloed organizations with standard functionality. This isn’t 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.

Effective People has custom-built an SAP CI-based extension, EP Permission Access Manager, as a solution to this problem.

Enhanced Access Management with EP Permission Manager

EP Permission Manager is a custom solution and is available only via Effective People.

EP Permission Manager allows you to automate the access request-and-approval process for key roles that you cannot grant based on dynamic groups.

Watch a demonstration of EP Permission Manager in action.

The solution is built and hosted on the SAP CI 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 extension comes with a range of features to fully support your organization’s access administration:

A simple access request configuration, including multi-step approval and flows

Notifications via email or directly to approvers’ SuccessFactors home pages

A “pending requests overview” page for users

Admin reports, allowing for central monitoring of all pending requests

Configurable support for multiple languages

An enhanced user experience, with SAP’s Fiori-based solution and Single Sign-On (SSO) with SuccessFactors

EP Permission Manager 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 learn more about EP Permission Manager and how to better manage your SuccessFactors access setup,  contact us today.

Purchase EP Permission Manager in SAP App Store.