Skip to Content
Technical Articles

Role Based Permissions in SAP SuccessFactors

This blog post introduces you to the recently published SuccessFactors Implementation Design Principle (SFIDP) document: SAP SuccessFactors Business Suite: Design and Implementation considerations for Role Based Permissions. Implementation Design Principle documents are owned and managed by SAP SuccessFactors Product Management who engage and collaborate with select, interested partners, and SAP Professional Services to tap the rich implementation experience that is distilled in the document after a formalized product review process before wider publication. For a complete list of published IDPs, please refer to the IDP publication page Implementation Design Principles for SAP SuccessFactors Solutions.

This IDP is authored based on experiences from implementations and support situations to provide guidance and reference to customers and partners who are either in the design stages or looking to review their current permissions setup to improve upon their initial design. This document is relevant not only for new SuccessFactors projects but also to those that are in post go-live support/maintenance.

Introduction

Without a good understanding of key concepts and an adequate RBP design, customers will encounter numerous challenges which should be avoided at all costs. Such issues may come in the form of legal fines due to misappropriation of sensitive data, degradation of system performance due to inefficient configuration, or possibly even increased operating costs due to complexity of design maintenance. To avoid these challenges, customers should develop robust security models during the onset of their implementation in accordance to the design principles outlined in the IDP document, as a poor RBP design can become increasingly difficult to roll back and untangle.

Security Design Requirements

At a high level the security requirements of any organization shall comprise the following:

  • Compliance with data privacy regulations
  • Maintain system performance
  • Ease of maintenance

Each of the above three requirements are non-negotiable and are of equal importance/priority. Many occasions the projects end up focusing primarily on the compliance with data privacy regulations and with less emphasis on the other two aspects. It is also attributed to the fact that the later 2 don’t unravel their full impact/downsides until advanced stages of the project or post go-live or over a period of time. The key to avoid such costly overlooks is to ensure to invest adequate time and effort in designing the security concepts and implementation of Role Based Permissions in SuccessFactors.

RBP Concept

SuccessFactors leverages a role-based permission framework, to manage system security. Often referred to as “RBPs,” role-based permissions consist of two components: permission roles and permission groups. Permission roles are comprised of various privileges to system data and functionality. Permission groups are populations of users that have been grouped together who share specific attributes. Permission groups can either be static – defined by specific usernames or dynamic – based on user attributes. These groups are further segmented into ‘owner’ and ‘target’ populations. Owner populations (also known as granted group) include users that are assigned permission roles, which grant specific privileges they can perform for or on their associated target population(s). Additionally, relationships (hierarchical or non-hierarchical) may be leveraged to assign permissions. The total number of permission roles and permission groups should be kept as low as possible, as too many will be difficult to manage and hinder system performance; however, the system does not define configurable limits.

The set of guidelines in the IDP have been created based on customer use cases and an understanding of the RBP infrastructure, that can be used as a framework when designing RBP for large customers with complex security requirements. It is worth noting that due to the complexity of the topic and the specifics of each customer, the outlined advice must be tailored to the concrete situation at hand.

Permission Role Design

To understand which permission roles are required, refer to your (customer’s) HR operational model which defines the various HR roles within an organization as well as their corresponding responsibilities and activities. The details encompassed in process maps will allow to identify which activities are performed and by which parties. The collective activities performed within SuccessFactors by each party will define your permission roles.

For example, imagine your process maps include a swim-lane for HRBP. Every process step within this swim-lane outlines an activity conducted by HRBPs. To configure your HRBP permission role, consolidate the steps involving SuccessFactors and translate them into specific RBP permissions. This will ensure any individual responsible for HRBP activities will have a permission role available that accounts for all access required to perform any steps defined within the process model.

Further, you now have a backbone to your RBP model – permission roles are defined by the process model – meaning, any adjustments to permission roles should be accompanied by a corresponding modification to the process model and vice-versa. Data privacy and protection should be incorporated in the design by default, access should be based on what is minimally required to execute allotted HR responsibilities.

Strive to develop a global role framework, as localized requirements will necessitate multiple variations of the same permission role.

­For example, when developing the ESS role, start with employee access that is consistent globally. If a country requires a deviation from this global ESS role, either the global ESS role would need to be changed (which would change access for all employees globally) or a net new localized ESS role would need to be configured and granted in addition to the global ESS role. Below screenshot shows the schematic representation of the approach. Note the permissions within the Global ESS role and individual country ESS Roles are disjoint or in other words have no repetition of same permission(s).

ESS%20Roles%20Overview

Every employee will get the Global ESS Role plus the Country ESS role that the employee belongs to. Below is the representation of role assignment for Country A employees.

This approach makes it easier to carry out changes that are global whether it is addition of a specific permission or removal, at the same time still making it possible to make local changes within the Country ESS roles.  Careful considerations have to be made before finalizing on a design approach based not only just upon the size and spread of the customer but also keeping in mind the ongoing maintenance efforts post go live, that are in line with the security/governance model practiced by the customer. Some of the pros and cons of the above design are listed below:

Pros Cons
Global changes can be made easily by updating just one single role Changes to the global role will affect the entire employee population
Local country specific changes can be easily made by updating the country specific role Good understanding of the current security design and stringent governance model required to decide which role the changes are to be made in
Fewer roles to maintain as opposed to having to maintain a single role for each country During a phased go-live by country, advance planning by all countries needed in deciding what goes into the global role

The document also covers the below topics that play a crucial role in the RBP security design.

  • Permission Group Design
  • RBP Workbook
  • Limiting number of users with access to manage RBPs
  • Separate access for specific admin roles
  • Engaging RBP consultant and RBP Business Owner during EC Design
  • Governance process
  • RBP Reports and Change Audit Reports
  • Naming convention
  • Check tool
  • ‘Extend by N days’ feature
  • Other permission considerations such as Associations, rules with workflows, reports, workflow design and relationships.

For more details please refer to the implementation design principle document.

Acknowledgements:

The IDP document SAP SuccessFactors Business Suite: Design and Implementation considerations for Role Based Permissions had valuable contribution from SAP SuccessFactors partners towards authoring that includes Nicholas Iodice from EY and Ankita Mistry from IBM.

                                         

                       Nicholas Iodice                                                            Ankita Mistry

Conclusion/Key Takeaways:

I hope this blog post helped you get acquainted with the basic understanding of the concepts & use cases defined and discussed in the SFIDP. I would encourage everyone to further explore the document for a full-fledged discussion that will aid in better product implementation as well as help in aligning with the industry leading practices. The SuccessFactors Product Advisory and Partner Success team looks forward to your valuable comments/feedback/queries on this blog post.

 

3 Comments
You must be Logged on to comment or reply to a post.
  • Hi,

    A great post highlighting the challenge of having a system that meets requirements vs one that meets requirements and is supportable. Great work.

    I do however, have a query. Could I please clarify the following statement made here

    “The total number of permission roles and permission groups should be kept as low as possible, as too many will be difficult to manage and hinder system performance

    I am not aware of any system performance issues related to numbers of permission roles or groups.

    Whilst I fully agree with the difficulty in managing large numbers of groups and roles, I don’t think those result in system performance issues.

    I’d be very interested to understand why this claim is made and what evidence there is to support it.

    Thanks,

    Chris

    • Hello Chris,

      Firstly, I am glad to hear that you haven’t encountered any system performance issues caused by the RBP design.

      A lot of things go into deciding the actual performance/response times of the system, such as number of permissions rules, number of assigned permission roles, the size of the target population of the roles assignment, the definition of the target population, granularity of the permissions, number of fields, number of custom objects(RBP relevant) and other transaction specific factors such as first time login (no caching), online user, API User etc.,

      Many of these contributing parameters are driven by business/customer needs such as number of users in the system/group, number of objects, number of fields etc., The guidance provided in the document including the one which suggests to keep the permission roles and groups to a minimum not only help us keep a tab on performance impacts but equally importantly the maintenance of the permissions/security of the system.

      Hope this helps.

      Regards,
      Tarun

      • Thanks Tarun,

        so to be clear there aren’t really any performance issues associated with having more permission roles if there are different permissions or even the same ones? Where I believe it might make a difference is if a person has many different roles for different populations? Which would require the evaluation of all of the different populations.

        Now, were that to be done in real time, every time a set of data was queried, that could have a performance impact.

        I’ve never seen such an impact, so whilst there may be so small increase in load to initially resolve populations covered by given RBPs, my guess is that SAP, being clever and trying to reduce the load that their servers are generating, are caching the permission checks, so no noticeable end user performance degradation no matter how many RBP’s you use.

        Either way – unless there is actually a performance issue which is relevant to the customer, this is actually SAP’s problem, not the customer’s.

        This is why I asked for some stats which might make me think about promoting restricting numbers of RBPs for performance reasons. It doesn’t look like you have any.

        Now I totally agree about restricting RBPs for ease of maintenance, but I’m just not buying the performance reasoning.

        hope that makes sense,

        Cheers,

        Chris