Peoplesoft Row Level Security Search Records

PeopleSoft Row Level Security Search Records

If an organization we are working with is using PeopleSoft as it's ERP solution then depending upon what role we play we do online transactions through various components in PeopleSoft. For example, HR users usually work in Production environment hence use components under Workforce Administration, Organizational Development, Workforce Development, Benefits etc… in order to carry out their daily business.

A Consultant (Technical or Functional) however will mostly works in Non-Production environment hence the components under the menus – Workforce Administration, Set Up HRMS, PeopleTools etc… are the ones where they visits most often to do transactions as required. A consultant at times needs to play various roles in order to expedite certain tasks part of theirassignment. For example: 

• Resolving a production issue by simulating it into Non Prod environment
• Validating a test scenario which is part of implementation
• Fig-Gap analysis

If we just forget about the role that one plays and list out few most common components a user deals with to carry out various transactions then the list will contain:

Transactions on Job data

·       JOB_DATA (Navigation: Main > Workforce Administration > Job Information > Job Data)

·         JOB_DATA_CURRENT (Navigation: Main > Workforce Administration > Job Information > Current Job)

·         ADD_PER_ORG_ASGN (Navigation: Main > Workforce Administration > Job Information > Add Additional Assignment)

·         ADD_HOST_ASSIGN (Navigation: Main > Workforce Administration > Global Assignments > Track Assignment > Add a Host Assignment)

Etc…

Transactions on Personal data

·         PERSONAL_DATA (Navigation: Main > Workforce Administration >Personal Information > Modify a Person)

·         DEPEND_BENEF (Navigation: Main > Workforce Administration >Personal Information > Personal Relationships >Dependent Information)

·         EMERGENCY_CONTACT (Navigation: Main > Workforce Administration >Personal Information > Personal Relationships > Emergency Contact)

·         DISABILITY (Navigation: Main > Workforce Administration >Personal Information > Disabilities)

Etc…

Hold on.. Why am I explaining all this when our topic here is “Row Level Security Search Records in PeopleSoft”?

Well, because all the components mentioned above, use security views as their search record and that is to ensure that a particular user who is doing transactions through these components, can see only those employees that they are allowed to see.I would like to list down those security views along with the components where they are used as search record:

   Components for Job data transactions

·         Job Data (JOB_DATA)  - EMPLMT_SRCH_GBL

·         Current Job (JOB_DATA_CURRENT ) - EMPLMT_SRCH_COR

·         Add Additional Assignment (ADD_PER_ORG_ASGN ) - PERS_SRCH_GBL

·         Add a Host Assignment (ADD_HOST_ASSIGN ) - PERS_SRCH_GBL

            Etc…

   Components for Personal data transactions

·         Modify a Person (PERSONAL_DATA)  - PERS_SRCH_ALL 

·         Dependent Information (DEPEND_BENEF) - PERS_SRCH_GBL

·         Emergency Contact (EMERGENCY_CONTACT) - PERS_SRCH_ALL

·         Disabilities(DISABILITY) - PERS_SRCH_ALL

            Etc…

As you can see, there are various security views created and are used in these components. Based on the component requirement, some of these views search for the employee data rows by EMPLID and EMPL_RCD and others just by the EMPLID.

For example, The view EMPLMT_SRCH_GBL used in Job data component considers EMPL_RCD field while searching the data row when a user hits on the “Search” button in the component search page whereas the view PERS_SRCH_ALL used in Personal Data component doesn’t consider EMPL_RCD filed while searching the data rows.

One easy way to find out the search record for a component, Just open the menu definition under which the component exists, in the Application Designer and locate your component, then right click on it and open the “Menu Item Properties”. Check what the search record for the component is and whether it has been overridden.

So, when the so called “Row Level Security Search Records” come in picture and how they secure the data from a user (HR Admin, Consultant etc…). This is also called Row Level Security in PeopleSoft.

Securing Data rows using Security Search Records (Row Level Security in PeopleSoft)

Let’s take any one of the component mentioned earlier. A new employee “ST01ST20” has been hired in the organization but when HR tries to open their job data through JOB_DATA component:

 

Oops..!  looks like employee doesn’t exist.

Is that what it looks like?  No, instead the HR user is not able to see the newly hired employee because they don't have access to them and this restricted access has been enforced with the use of the row level security view EMPLMT_SRCH_GBLas search record in this component. 

So let’s find out what exactly happens behind the scene and how the security search view works to ensure the unintended employee data shouldn’t be displayed to HR user.

   In the search page, when we enter the EMPLID ‘ST01ST20’ and hit enter:

     

   Hope everything is clear so far and if it is then let’s give data access to the HR user so that they can see the data rows of employee ST01ST20. There are various different ways such access can be given and for now we will just add business unit “AUS01” to the Permission list TEST_PERMSN (Navigation: Main > Set Up HRMS > Security > Core Row Level Security > Security By Permission list).  

  Note that, this access can also be given through “Security by Dept Tree” component    which exists under the same menu. In this method, the HR users are given access to the intended department defined in a Department tree where a particular employee belongs.
After the access is given to HR user let’s see what happens: