Security Permissions in SuccessFactors
There are few customers who are still living with Non-RBP features (Legacy Permission Framework) in SuccessFactors called Administrative Domains and this is not compatible for new features which is getting released by SuccessFactors every quarter of a Year. We should consider new Employee Central V2 version which has made it pre-requisite to have Role Based Permissions mandatory.
Role Based Permissions (RBP)
Role Based Permission allows granular secular management with Field Level Permissions in SuccessFactors. Role Based Permission defines permission roles and permission groups which would be assigned for a user with specific target population. It means a specific role can have permission to view/edit/create/delete any field in SuccessFactors for specific Target users (Population).
RBP framework includes Structural-based Permissions at standard but limited to authorizations for a manager and 3 levels below. We can control the permissions at almost all fields, menu items and actions in Employee Files in Employee Central.
The basic concept of RBP framework is mandatory for a SuccessFactors Consultant when going with transition from Non-RBP to RBP. We need to understand RBP concept in detail as described below
- Granted Users = users assigned with a role that are defined with security permission
- Permission Role = group of permissions assigned to specific Role
- Target Population = population of users that are accessed using the permissions
The following activities are pre-requisites for transition to Role Based Permissions in SuccessFactors. This is required for smooth transition.
- Standard Role Based Permission’s Workbook with Permission Roles & Permission Groups
- Creation of Superadmin Role from Provisioning
- Activation of Synchronization between two instance to move permissions to target instance
- Both instances (Test & Production) are on same releases
Best Process to maintain RBP
Instance must have Role Based Permissions with best practice which impacts system performance and maintenance efforts in mind. It is also crucial to have a good governance process in place for any further changes. We must keep the following points in mind to maintain best practice of RBP.
- Use standard roles (most generic roles)
- Avoid Redundancy
- No overlap between Roles
- Limit the number of Roles and Groups
- Naming Conventions to keep the Roles & Groups unique
The following caveats to be considered while maintaining Role Based Permissions.
- Only one permissions framework can be used at one time: if a customer is using ADs for existing modules and one modules requires RBPs, then RBPs must be implemented for all existing modules
- Module-page permissions for Performance Management, Goal Management, Compensation, and CDP are controlled at the form level
- SuccessFactors can slow down with bad RBP design (e.g. getting the same permission from different roles)
- Dynamic groups are to be created manually. There is no facility for upload through csv files whereas Static groups can be uploaded manually.
Rigorous Testing of Permission roles and group in an Instance
Each permission role and group must be tested rigorously before synchronizing the instance with production. It is the key activity in the process of RBP configuration. Each role with permissions must be tested to ensure permissions are granted as per customer requirement. The following pre-requisites are to be confirmed for complete Testing of roles.
- Data is complete in the test Instance. The copy of production data or real sample data in Test instance would suffice
- Each Role is assigned to specific group contains the real data scenarios
Copy RBP Configuration to Production Instance
Once all tests are performed and RBP Configuration of Test instance is ready to be copied to production instance, the following activities to be performed.
- Granting Permissions to Use Instance Sync Tool to Super Admin Role – Select Super Admin Role, Click on Take Action -> Edit, Select Permissions and Under Administrator Permissions, select Manage Instance Synchronization.
For synchronization of Permission Roles & Groups, select Sync Permission Roles and Sync Permission Groups and Done.
- Copy Roles & Groups– Choose Admin Center->Company Settings-> Synchronization Instance Configuration which opens Configuration Sync Wizard
- Select the Target Instance, groups and roles to be copied
- The user ID who created the group in the source instance must also be a user in target instance for the sync of the groups to be successful.
- Overwrite the existing RBP groups on Target System – There is an option to overwrite the existing roles and groups, if YES, it overwrites & No, it won’t copy the roles and groups
- First synchronize all attached groups with the target instance
- Templates, families, roles, picklists and further data associated with the roles in the source instance need to exist in the target instance for roles to be successful
There is an option to choose “Test Sync” to evaluate the results. During the test run, if the sync is successful, you can see number of groups copied in the “UI” with “Add & Update Count”
You can also see successful message in downloaded report.
If it is not successful, we can see “Failed Count”
We can also download and see the report with the reasons as per below screen.
If you satisfy with Successful, we can do “Run Sync Now” to actually copy the groups and Roles
This is a really useful blog. Many thanks for taking the tie to create it. Please would you advise where I can get hold of a copy of the 'Standard Role Based Permission’s Workbook with Permission Roles & Permission Groups' that you mention. I haven't been able to locate it on PartnerEdge but then SAP keep moving things around. They don't make it easy to locate things!
Janet Grainger Lee (email@example.com)
We are looking at implementing SuccessFactors and the ‘Standard Role Based Permission’s Workbook with Permission Roles & Permission Groups’ would be helpful to me and my team as well.
We are implementing Employee Central in couple of weeks and looking for help with setting up the permissions for IT Admin role. Is there a standard set of permissions which needs to be given to the IT Team members who will be supporting the application once it goes LIVE.
I understand every company will have different requirements, but looking for a standard set of permissions.
I would be interested to learn if there is such a "standard set of permissions" that we can keep the role secure while allowing our IT team to support the application as well.
Also what's the recommended permission set (best practices) for regional admin who is allowed to deploy training for certain domain or Org instead of deploying a training to the whole (global) company? How do we know if we are on RBP or non-RBP? Thanks!
Hi Poorna , Is there a way I can find if we are using Administrative domains (Legacy Framework) in our LMS system instead of latest RBP ? Please confirm
Tks for these Tips!