SAP Knowledge Base Article - Public

2321200 - BizX Platform - Troubleshooting RBP issues : Admin tools & reports [Including Check Tool]

Symptom

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

 "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 HCM Suite

Resolution

Checking Users Permissions

In order to view what permissions users have, we can use 3 different tools depending on what we want to check:

  • 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) that is 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.

For step by step details on using the above tools and reports, see the RBP Admin guide on http://help.sap.com/hr_foundation

Working with RBP Check Tool

In order to identify potential configuration issues in Role-Based Permission, you can use Check Tool. For more details about Check tool please refer to the guide: Using the Check Tool

Below you can find the list of possible diagnostic from check tool, details about each one and actions to be taken to resolve the 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 above case one possible improvement would be remove User Search permission from All Employee search and Login or Employee Self Service, because both are granting the same permission with 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 above case a possible improvement would be 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

Reference RBP Troublshooting Guide for more details

Keywords

CheckUserPermissions, RBP, Check Tool, CheckEveryOneGroup, Role-Based Permission, Permission
, KBA , LOD-SF-PLT-RBP , Role Based Permissions , LOD-SF-PLT , Foundational Capabilities & Tools , Problem

Product

SAP SuccessFactors HCM Suite all versions