SAP Knowledge Base Article - Public

2321200 - Troubleshooting SAP SuccessFactors Platform Role-Based Permission (RBP) Issues

Symptom

  • Admin: User role search feature
  • Admin: View user permission feature
  • Admin: RBP Permission reports in Ad-Hoc reporting.
  • Admin: RPB Checks
  • Comparing specific permissions between two users
  • Viewing all permissions assigned to one user, as well as the roles granting these permissions
  • Users can see something but they should not. How to check if this is a permission configuration issue, or a bug

Image/data in this KBA is from SAP internal systems, sample data, or demo systems. Any resemblance to real data is purely coincidental.

Environment

SAP SuccessFactors HXM Suite

Resolution

Checking Users Permissions

In order to view what permissions users have, use the following three tools, depending upon information needed:

  • User Role Search tool: User Role Search can search the roles granted to specific users for a specific permission and a target user. When some users get some permissions on some target users that should not be granted, the administrator can use this tool to find which role grants the permission so they can update the permission settings.

  • View User Permission: Run the View User Permission report to determine how, through which role, the permission was granted to the employees. For each permission you will be able to see the permission role (or roles) granting this permission to the user; however, the tool does not show how the role is linked to the user. 
    If that does not clarify how/why they have that permission, or creates concern about where else this permission is visible, then use the RBP Permission to User Report with the Single Permission Filter to validate what other groups have access to this permission.

  • Ad Hoc reports: You can create an ad-hoc permission report to see how users are being granted permissions. For example you can use the RBP Permission to User report to report on specific permissions and how they are being granted to users.

Note: For further details, see Using Role-Based Permissions > Troubleshooting

Working with RBP Check Tool

  • In order to identify potential configuration issues in Role-Based Permission, you can use Check Tool.

Note: For more details about Check tool please read Using the Check Tool

  • See below for a list of available diagnostics in the Check Tool, details about each one, and actions to be taken to resolve any issues.
     

 

Check ID

RBP Check Name

Description

Proposed Solution
  1.  

CheckEveryOneGroup

Verify if the Everyone group exists.

This check validates that the Everyone group exists for the user. When trying to associate a group to a role, you may encounter errors if the Everyone group does not exist and has not been created.

Disable RBP and then enable RBP.
  1.  

CheckRoleRuleAccessGroupUser

Verify if roles exist that are not associated with access permission groups or users.

If your system contains roles that are not associated with access permission groups or users, a run-time exception occurs when the group or user is refreshed or when the target population is calculated. This check validates if there any roles that exist without permission groups or users.

Please execute any of the proposed recommendations below for the roles listed in Results section:
1. Associate Permission groups or users that you want to grant this permission role to.
2. Deactivate the rules that are not currently associated with any permission groups or users. 
3. Delete any rules that are not associated with permission groups or users.
  1.  

CheckRoleRuleTargetGroup

Verify if roles exist without target population defined.

This check validates if there are any roles in your system that do not have a defined target population. If your system contains roles that require the target population to be defined and there is no target, a run-time exception occurs when the groups or users are refreshed or when the target population is calculated.

Please execute any of the proposed recommendations below for the roles listed in Results section: 
1. Specify the target population for whom granted users have permission to access. 
2. Deactivate the rules that are not currently associated with any target population. 
3. Delete any rules that are not associated with a target population.
  1.  

CheckAccessGroupNameLength

Verify if the access group names associated with a rule exceeds 1000 characters.

Each "Permission Groups or Users" row on the “Permission Role Details” screen represents a rule. This test validates if the total length of access group names that are associated with a rule exceeds 1000 characters. Access groups with 1000 or more characters may cause errors when running an RBP ad hoc report.
  • For each role in the Results section, review the highlighted rules.
  • Create a new access group that includes all the access groups associated with a rule. Or condense the current access groups into fewer access groups.
  • Replace the current access groups with the newly created access group.

You can also rename the associated access groups so that the total number of characters does not exceed 1000.
  1.  

CheckTargetGroupNameLength

Verify if the target group names associated with a rule exceeds 1000 characters.

Each Target Population row on the “Permission Role details” screen represents a rule. This test validates if the total length of target group names that are associated with a rule exceeds 1000 characters for a role. Target populations with 1000 or more characters may cause errors when running an RBP ad hoc report.
  • For each role in the Results section, review the highlighted rules.
  • Create a new target group that includes all the target groups associated with a rule. Or condense the current target groups into fewer target groups.
  • Replace the current target groups with the newly created target group.

You can also rename the associated target groups so that the total number of characters does not exceed 1000.
  1.  

CheckUserPermissions

Verify if a user has been granted the same permission more than 30 times

This check verifies if a user was granted the same permission more than 30 times. One user might be granted the same permission as part of different groups within the same role or different roles. This can cause a performance downgrade when calculating the target population.
  • Determine roles starting by the Permission Basic Roles first including the most common settings for all users. This is expected to be the Role Everyone, Employee, Manager, HR and Administrator. If a permission has been granted to everyone, it never needs to be repeated again in another role. A user in multiple groups gets the combined permissions of all groups they are a member of.
  • For additional roles, work on an exception basis and include only the unique extra permissions that the role should have beyond other roles.
  • Avoid Duplication of permissions across roles.

 See Example in the following section
  1.  

CheckRulePerRole

Verify if the number of rules associated with a role exceeds 100

 

Each row with “Permission Group or User” and “Target Population” on the “Permission Role Details” screen represents a rule. This check validates if there are more than 100 rules associated with the role. Calculating the target population with more than 100 rules leads to a degradation of performance.
  • Please minimize the number of rules by combining them into fewer rules and then re-associate to the role.
  • In case you have specific needs and you are not able to combine the rules, split them in different new permission roles that do not exceeds 50.

 

 See Example in the following section

Examples:

CheckUserPermissions

When viewing individual permissions under User Role Search, a user should not have multiple roles per permission.

 CheckUserPermissions.png

In the example above, an improvement would be to remove the User Search permission from All Employee search and Login or Employee Self Service, as both are granting the same permission to the same target population.

CheckRulePerRole

When viewing an specific role under Manage Permission Roles, a role should not have multiples rules, which can be identified as the step "3. Grant this role to..." of edition/creation of a role.

 CheckRulePerRole.png

 In the example above, an improvement would be to split rules per region, creating Permission Roles like "Americas", "Asia", "Europe" and associated the rules by country:

  • HR Admin BR > Americas 
  • HR Admin DE > Europe
  • HR Admin CN > Asia

See Also

Keywords

sf, success factors, PLT, bizx, CheckUserPermissions, RBP, checktool, rights, CheckEveryOneGroup
, KBA , LOD-SF-PLT-RBP , Role Based Permissions , LOD-SF-PLT , Platform Foundational Capabilities , How To

Product

SAP SuccessFactors HCM Suite all versions