Role-Based Permissions Quick Guide for Implementations

[Pratima]

Key Considerations When Creating a New Role:

1. Clearly define which processes will be managed by the role. This ensures that permissions align with the tasks and responsibilities associated with the role. Example for HR role the tool access becomes crucial to manage HR tasks example data update in manage data or position org chat or manage position. Whereas for an employee role these HR tools access is not required.
2. Identify who will be in the granted population and who will be the target population. This helps in setting appropriate access levels and maintaining data security. Identify criteria to create the granted group example static groups will have user or username whereas dynamic group can be combination of a field from position or job along with Foundation object. Create target groups using foundation objects like employing entity or country etc.
3. Determine the relationship between the granted and target populations. For example, is it a line manager and direct report, or HR and employee? Understanding these relationships is crucial for setting accurate permissions. The associations of role can be enabled using relationships like line manager, matrix manager, HR business partners, custom manager etc.
4. Decide the level of security required based on the permissions. For instance, roles created for employees typically have more restrictions compared to roles created for Global Centers of Excellence (CoE), where organizational and related information may be less restricted. For HR roles as well organisation data access is granted to fill in the data while creating positions or add new employee processes.
5. Enable reporting permissions as per the requirement. Example for some roles there might be a requirement to only enable reporting access while restricting system access.
   • Finalize the functionality which need to be enabled Adhoc, Canvas, or Story Reports.
   • Then enable relevant permissions like for adhoc domain grant separate domain access for create and run permissions under Reports permission section.
   • For canvas enable functional permission named canvas and detailed reporting under Analytics permission section.
   • For story create story permission in Reports permission section and then relevant data access from each module. Do not forget to enable user access in manage user section.
   • If the role is created for Performance, Compensation, or Variable Pay module then template access and document related permission need to be enabled. Also enable executive review.
   • Finally enable general permissions example: Report Center, schedule permissions, share reports to roles etc.

Basic Steps to Review Permissions in a Newly Created Role

1. Before creating any new role check the existing roles to make sure there is really a need to create new.
2. Check if any non-targeted permissions or admin permissions are enabled which when overlapped might enable more permissions than intended. Example OData admin, manage business configurations, etc should not be enabled for HR roles.
3. Verify that the permissions are in line with the "need to know" principle. Enable sensitive data fields considering the information from the legal point of view to avoid any data incident.
4. If any MDF objects permission is granted example employing entity, ensure that restrictions are added in role to group association to limit the values of employing entity for local HR configuration.
5. Enable the inclusion or exclusion checkboxes in role association to exclude HR to have same permission for their own profile.
6. Identify if the permissions of the new role are not overlapping with existing roles where the granted and target are the same as the new role. Example first name, last name fields if globally enabled for all users to see everyone’s first name and last name then these permissions are not required to be enabled in any other role as the global role will enable the access for all users.
7. Ensure the naming convention limits the characters in a single association to be less than 1000 characters. If many groups need to be added in single association, then the character length of all groups together should not exceed 1000. This association will also get flagged in check tool.
8. If possible, limit the number of associations to decrease performance issues. The performance issues when editing any role are proportional to number of associations. In other words, too many associations will cause performance issues when updating that particular role.
9. Test the role for few negative scenarios maintain data security. Example scenarios:
   • HR should not be able to hire an employee outside target.
   • HR cannot report on employee outside target population.
   • Line manager should only see and report on direct repartees.
   • Homepage tiles are enabled as per requirement.