Every SAP SuccessFactors implementation project requires the design of Role Based Permission (RBP) which is the only permission framework available.
Please find below some of the points which are observed and learned in my previous projects and some of these are also covered in Implementation design principle for RBP.
- Design for the norm, not the exception
- Think “business value” and look for a common ground
- Strive for fearless transparency in designing the roles.
- Establish clear roles and responsibilities within the organization
- A super admin role with full access to all system permissions who understands the data used to support each of the functionalities, preferably with a back-up
- A system admin role to manage the necessary integrations, SSO and other technical settings, ideally someone from IT team
- Use of dynamic assignment to granted permission groups, wherever possible
- Clear definition and understanding of business role-based permission roles like Employees, Managers, HR Admin, HRBP etc., and module-based permission roles like mobile, talent pools, Succession Planning etc.
- Start the RBP design with target populations groups as they are more complex than granted populations groups
- After granted and target population groups, then design and configure the permission roles with actual permissions
- When defining target groups, think in terms of taking the target population and then cutting off to reach the right population, rather than trying to combine conditions to build up the population through multiple people pools.
- Layer the permission roles carefully to keep the design simple, yet covering all scenarios
- To leverage existing RBP structure (in the case of brownfield implementations) as much as possible thus minimizing the config changes and maintenance when implementing new modules
- Start with high level roles like Public, ESS, MSS, HR Admin, HRBP etc.
- Aim for role re-use where it makes sense
- Avoid overlapping permissions granted by multiple roles
- Admin roles divided up my module, especially for organizations with a large SF footprint
- Extra care when a user is assigned to multiple groups as they get combined permissions of all the groups, they are members of.
- Sensible naming convention for groups and roles
- Clear understanding of the governance model with answers to below questions –
- Who will make the change?
- How can change be requested?
- Who needs to review, decide and approve the change?
- The key element of the RBP deliverable is the security matrix (RBP Workbook) which consists of data fields and system features as rows and security roles as columns. Better to agree upon the template of the matrix
- Significant updates to the security matrix are usually time-consuming, due to the complexity of the system (this applies to both the design document itself and the system config). Better to agree upon the ownership to maintain the matrix
- Avoid discussing details early on, instead spend more time on structuring the plan around RBP
- Up to date alignment with RBP workbook to document the RBP structure including capturing notes for changes as the source of truth
- Two primary aspects of an RBP design will influence system performance – total number of permission groups and overlapping permissions granted by multiple roles; ideally, both should be minimized as much as possible
- Understand the RBP reporting possibilities along with audit reports
- To make the customer understand that RBP does not cover any permissions that are managed via templates (legacy security framework). The permissions continue to be driven by the code in the form/plan templates for Performance, Objectives, Development
- To know and understand the possibilities and limitations in copying the permission roles and groups from one instance to another
- Discuss the ways of working on RBP design, workbook update and configuration with customer counterpart. Usually the workbook is going to be very vast and loosing the track of updates will need to reconcile all permissions to get back in sync
- Indirectly, RBP configuration acts as a unit test even for other areas of implementation. Hence testing of RBP should be given utmost priority.
- RBP configuration to be started only after loading the data like pay components, event reasons etc.
- Be careful with all temporary and non-production roles in the system when moving them to production instance.
RECAP
This list could not be an exhaustive list of design principles while structuring the permission framework for an organization, but I hope this would help the consultants as a starting point for such discussions.
Thanks for taking your time in reading this blog and leave your comments, if any for further clarifications. Thank you!
