Sunday, March 23, 2014

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 their assignment. 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
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_GBL as search record in this component.

Please also see
'Override Position Data' and 'Use Position Data' Option in Job Data Page
Hiring a Person in PeopleSoft
How to find the List of Users Assigned to a Role
How the Various Date Fields on Employment Data Page are Updated
Simplified Way to Provide a Page Access in PeopleSoft
How to Resolve a Row Level Security Issue in PeopleSoft
Part Time/Full Time, Regular/Temporary and Contingent Workers in PeopleSoft
SQL Query to Find Direct Reports for a Manager in PeopleSoft
Understanding Component Interface in PeopleSoft 
How the FTE is Calculated in PeopleSoft
Business Unit, Company and Regulatory Region in PeopleSoft



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: 

9 comments:

  1. Good explanation, however the search record in the example is not EMPLMT_SRCH_GBL, as you can see from the menu it is overwritten by a custom search record FMC_EMP_SRC_CR2.

    ReplyDelete
  2. Sorry, I didn't intend to show that as its all about Delivered functionality. Have corrected it now.

    ReplyDelete
  3. Very good explanation.. very useful.. Thanks to Sunny Sharma..!

    ReplyDelete
  4. Hi Sunny,
    I have a scenario of multi company, each employee can be transfered to another company.
    Transfers are recorded under same Emplid/empl_rcd, with consecutive actions of 'termination' from source company (effdt-seq 0) and 'rehire' in target company (same effdt-seq1).
    To manage each company, i have permission lists set for each group of HR Managers (per company)
    The problem is that when a employee gets transfered to another company, the source company HR Manager no longer finds the historical data on her company.

    How can I change the security search record and enable viewing historic data for those employees, when they get transfered?

    Could you please give me some thoughts about it ?
    Thanks in advance.

    ReplyDelete
    Replies
    1. Hi,
      Please let me know the solution that you used to overcome the above issue.

      Delete
  5. Hi
    I have read that 'Security by Permission List' normally assign to roles and then to user profiles, NOT through User profile-General page(which is used by 'Security by Dept Tree' permissionlists).The above screen shots are not supporting that..
    Could you correct if I am wrong?

    ReplyDelete
  6. Hi ,
    How does this security work , is there any runtime parameter to check which oprid has logged in and where is the Security join lies in EMPLMT_SRCH_COR.

    ReplyDelete
  7. Hi ,
    How does this security work , is there any runtime parameter to check which oprid has logged in and where is the Security join lies in EMPLMT_SRCH_COR.

    ReplyDelete
  8. This comment has been removed by the author.

    ReplyDelete