HCM Functional: How to Resolve a Row Level Security Issue in PeopleSoft

 

How to Resolve a Row Level Security Issue in PeopleSoft

 

Most people prefer using SQL queries if they need to find out what are all the users have access to a particular employee's data in PeopleSoft and that's because either they are extremely comfortable with SQL or they don't know how to do this through an inquiry page in PIA.

 

 

Let's say an HR user reported you an issue that they can't see one employee's data in Job Data page. I would say this is one of the most occurred issues a PeopleSoft security consultant deals with as part of their daily work.
Anyway, from further inquiry you came to know that the employee's data row wasn't future dated because if it was then there is a separate security setup has to be done in order to allow users to see future dated transaction data in Job Data page.


So what are we gonna do now ? well, there are ways to analyze and resolve the issue but I am gonna tell you few very simple steps to the same through PIA:

Step 1: Inquire the security data for the employee

Open the Security Data Inquiry page (Navigation:  Main > Setup HRMS > Security > Core Row Level Security > Security Data Inquiry) and enter the employee ID for which the issue has been reported and then click on the button 'Show Security Definitions' to open the security configuration.

  

Here you will see all the Security Types which have access to the employee's data records. Note that if employee has more than one EMPL_RCD then it will show the security access for all of them.

Select all the rows and click on the button 'Show Permission List' to open all the permission lists those have access to the selected Security Type.

 

 

Select all the permission lists and then click on the button 'Show Users' which will finally open the list of users who have above permission lists assigned in their user profile respectively. 

 

So what do we finally have with us ? 

We have list of users who have access to the employee data for which the issue has been reported. Now, we have to find out whether in this list the HR user who reported the issue, exists or not. If they doesn't exist then it means we have to update the security setup for this HR user so that they get access to the employee's data.
Click on Find link and search the HR user id if it exists.


In case, the HR user exists in the list then it means that they have access to the employee's data and it is perhaps a cache issue which could be resolved if we just log out of the system, clear the browser cache and log in back again. 
However, if the HR user is not there in the list then we have got to update the security configuration for the user in order to provide access to employee's data hence go to the step 2.

Step 2: Update the Row Level Security Configuration

Once we are certain that the HR user cannot see the employee's data in Job Data page because their row level security configuration is not updated properly then the only area we have to focus on is, how and where to update the row level security configuration. Please note that, the terms 'Row Level Security' and 'Data Security' both are same in this context.

I would like to underline this point that, the row level security configuration is assigned to a permission list and this permission list can be:

·                The 'Row Security Permission List' which exists on the 'General' tab of User Profile page (Navigation:  Main > Setup HRMS > PeopleTools > Security > User Profiles > User Profile).

·                Any permission list added to a particular role which exists on the 'Roles' tab of User Profile    page (Navigation:  Main > Setup HRMS > PeopleTools > Security > User Profiles > User Profile).

In either case, the security configuration on the permission list is added/updated from below two places:

 1. Security by DEPT tree (Navigation:  Main > Setup HRMS > Security > Core Row Level      Security > Security By Dept Tree) 

This page uses Department Tree to enforce the row level security in PeopleSoft. for this, the department tree has to be maintained properly i.e, it should be refreshed frequently so that it does reflect the actual department hierarchy of the organization.

 2. Security by permission list (Navigation:  Main > Setup HRMS > Security > Core Row Level  Security > Security By Permission List)

Security configuration in this page is done based on the Security Sets and their Security Types. In this page, we only setup what are all the Security Types under a particularity Security Set that a permission list will have access to. The further access to employee records by Security Types is defined in transaction SJT table SJT_PERSON.

Most organizations use this page to configure the data or row level security so I will take this as reference when explaining how to resolve the data security issue further.
Lets get back to the issue at hand

By the end of Step 2 we would be certain that the HR user doesn't have access to the employee' data and its not a cache issue. So, how to resolve this now ?  Let's go to Step 3.

Step 3: Assign the data/row security to the HR user

We got to be careful here while doing any changes. You must follow below steps:

 

·                Find if there is any existing relevant role which has access to that employee and can be assigned to the HR user. If there is any such role then before assigning it to the HR user, make sure that the role doesn't have access to unintended data which HR user will also get access to if assigned. If everything looks green, assign the role to HR user.

·                If there is no such role, then check if any Permission List exist which has the same access. Also, make sure it doesn't have access to unintended data just like the way we analysed for existing role in above step. If all OK then find out an existing role to which this permission list can be assigned. If such role is found then assign the permission list to the role and then assign the role to HR user. Again, before assigning the role to the user, make sure it doesn't impact the other users access for which you first need to see what are all the users this role is tagged to -

How to find the List of Users Assigned to a Role

·                If there is no such permission list also, then as the last option we have to create a new permission list, then assign it to either existing or a new role then finally assign this role to the HR user.

All done, check if HR user got the required access.

 

However, I would like to reiterate few things here - Before making any changes in the security setup (As explained in the above steps), you must keep in mind that the changes shouldn't impact the existing data accesses i.e the data/row security access defined for other users shouldn't be impacted.