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 Permissio.... 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.
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.
At a high level the security requirements of any organization shall comprise the following:
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.
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.
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).
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:
The document also covers the below topics that play a crucial role in the RBP security design.
For more details please refer to the implementation design principle document.
The IDP document SAP SuccessFactors Business Suite: Design and Implementation considerations for Role Based Permissio... had valuable contribution from SAP SuccessFactors partners towards authoring that includes Nicholas Iodice from EY and Ankita Mistry from IBM.
Nicholas Iodice Ankita Mistry
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.
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).
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 Permissio... 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.
- SAP Managed Tags:
7 Comments
| User | Count |
|---|---|
| 4 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 2 |
