by Purnima Pandey & Sarayu Raghavan, 19 Sep, 2016
Ever imagined a situation wherein one employee could view the salary of another? Or worse still, if they could see the ratings of one another? Sounds alarming right! Data privacy and security are vital areas for HCM customers. As an HR practitioner, how do you ensure the privacy of data in your HCM suite? How to ensure that the right person has the right access to the right data?
All of these challenges support the need of choosing an HCM suite with robust permission settings- a Role Based Permissions (RBP) framework, like the one in SAP SuccessFactors. The RBP framework for SuccessFactors is not much different from the authorization concept in SAP.
What is RBP?
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. It allows for granular management of field-level permissions.
How to make the most out of RBP?
As we pretty much know about RBP, how to make use of it effectively? Once coached, every SAP SuccessFactors customer can make the most out of this robust framework. From our experience, we list out few best practices which we believe can make a significant change to your Role Based Permissioning.
1. Start Setting the foundation with generic roles :
It is always good to start configuring the most generic roles such as “All Employees Role” first and think wide of the permissions to be given to everyone. Let me take the help of an example. For the “All Employees Role”, the publicly viewable fields can be included in the Employee Profile. Do not include this field for other roles since users would already have the field granted to them using the “All Employees Role”.
Also, try not to replicate permissions in different roles if not required. Work only on an exception basis when you are creating more roles. Only the unique extra permissions that are required for the role is to be added.
- Uniform RBP structure
- Better data transparency
- Access of personnel data will be restricted
2. Use of lesser roles can do wonders!
As a best practice, it is advised to maintain only one role for ESS or MSS or HR. Avoiding creation of multiple roles for separate functionality helps reduce redundancy. Each of the Permission Roles will have separate permissions groups as Target population and each Permission group will have various criteria like country, department, division, sub-band/band etc.
The permission should be designed based on target population and region based specific permissions should be created. The Position based permission will be based on region. Permutations and combinations can be used to set up filter to decide the population.
- Reduction in multiple roles
- Ease of troubleshooting in case of Permissions issues
- Dynamic in nature
3. Create one Security Admin
Maintain one security admin who will be authorized to grant or revoke permissions in essential circumstances. Create a dummy user and associate the super admin role to it. Let’s look at the example to understand why you need to create a dummy user – If a user is made superadmin and he/she leaves the organization, it becomes a challenge for the organization as the permissions are associated with the user and get revoked once the user leaves. Hence it is better to create a dummy user (admin) and have the dummy user associated with the superadmin.
4. Select highest parameter for target population in the group
Always select highest parameter for target population in the group such as a legal entity and not a division or department. Let me quote an instance that one of our customers faced. The ESS role was assigned to a group categorized as per a department. Due to organizational restructure, a set of employees were taken out of the department and put under a different department. It became a huge problem as it impacted the permissions and the employees were not able to access the system until the permissions were restored.
To avoid such problems, it is advised to set the highest parameter for the target population.
5. Separate admin for separate module
Maintaining separate admin for different modules (be it comp or WFA or REC) is better as it is easier to maintain and add users in future. You can decide on the admin who can control the separate modules and it also gives a sense of ownership to them.
- The admins will have access only to the required and must have data
- Avoiding complexity in managing module based permissions
- Helps administrators in troubleshooting RBP issues for permissions
6. Specifying the Hierarchy
You can specify the number of levels in hierarchy for the target population while granting permissions using hierarchical relationships. 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.
And for the non-hierarchical relationships (HR, Matrix, Custom managers), you can follow it upto level one. For further levels, you can cross over to the standard manager hierarchy.
Few extra points to be taken into consideration :
- Keep the number of roles and groups to minimum – It helps avoid inconsistencies in RBP structure.
- Naming conventions – Keep the naming conventions unique for the roles and groups.
- Governance- It is good to define governance at the earliest. It defines who should be able to make changes and how the changes should be handled.
The RBP framework makes the solution scalable and accessible with the required level of granularity. The investment in a comprehensive design of SuccessFactors RBP functionality should be a central tenet of any Employee Central implementation. The recommendations detailed in this article will help you to successfully guide your SuccessFactors Employee Central implementation.
If you are an organization which values employee data security and wants to tighten the management of the Roles Based Permissions in your SuccessFactors instance, please reach out to firstname.lastname@example.org.