Security Permissions in SuccessFactors

Security level permissions are key activity where users will be maintained with relevant access as per their role.   Few customers are still living with SuccessFactors Non-Role Based Permission features (Legacy Permission Framework) called Administrative Domains. This legacy framework is not compatible with new features being released by SuccessFactors on each quarter of the year.
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 to a user with the specific target population.  It means a specific role (user) can have permission to view/edit/create/delete any field in SuccessFactors for specific target users.

RBP framework includes structural-based permissions as standard but limited to authorizations for a manager and down to three levels One can control the permissions in almost all fields, menu items, and actions in employee files in Employee Central.
The understanding of   Role Based Permission framework is mandatory for every SuccessFactors consultant.  Let us understand RBP concept in detail as described below

• Granted Users users assigned with a role that is defined with security permission
• Permission Role group of permissions assigned to specific Role
• Target Population population of users that are accessed using the permissions

Pre-requisite
The following activities are pre-requisites for the smooth transition to role based permissions in SuccessFactors.

• Standard Role Based Permission’s Workbook with permission roles & permission groups
• Creation of Superadmin role from provisioning
• Synchronization activation between two instances to move permissions to target instance and both test & production instance are on same releases

Best process to maintain RBP
The instance must have role based permissions adhering to best practice and keeping in mind impact on system performance and maintenance efforts. Good governance process should be in place for any further changes. Points for maintaining best practice of RBP.

• Use standard roles (most generic roles)
• Avoid redundancy and overlap between roles
• Limit the number of roles and groups
• Naming conventions to keep the roles & groups unique

Caveats for maintaining role based permissions.

• Only one permissions framework at one time: if a customer is using ADs for existing modules, requires RBPs for even one module, then RBPs must be implemented for all existing modules
• Module-page permissions for performance, goal management, compensation, and CDP are controlled at the form level
• SuccessFactors slows down with bad RBP design
• Dynamic groups are to be created manually and cannot be uploaded through csv files.

Rigorous testing of permission roles and group in an Instance
Each permission role and group must be tested rigorously to ensure each role with permissions must be tested to ensure permissions are granted as per customer requirement. Comprehensive testing is must before synchronizing the instance with production and also in the process of RBP configuration.
Pre-requisites for complete testing of roles.

• 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

  

• For the synchronization of the groups to be successful user ID who created the group in
• Overwrite the existing RBP groups on target system – There is an option to overwrite the existing roles and groups by choosing option “YES” or “NO”

  

• 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 the number of groups copied in the “UI” with “Add & Update Count.”

If it succeeds it shows up successful in downloaded report and if it is not successful, we can see “Failed Count.” If you are satisfied with successful result you can “Run Sync Now” to copy the groups and Roles.
You can read the same blog in detail by Poorna Murthy : (click here)
Visit Our SAP SuccessFactors HCM suite to transform your HR functions!
Poorna Chandra Murthy Akurathi, Principal Consultant – Pre-sales & Delivery – SAP HCM/ SuccessFactors @YASH Technologies

• Role Based Permission
• SAP
• Security Permissions
• SuccessFactors