PS 9.

1
Re-implementation
Employee Data Security
Prototype

Client Name:

American Express

Copyright 2006, Affiliated Computer Services, Inc. (ACS).

All rights reserved.
No part of this publication may be reproduced in any form without the written permission of ACS, Inc.

Revision History
Project
Version
1.0

Date
April 15, 2009

Revised By

Revisions

Ketan Dedhiya

Initial Version

Contents
1.

Introduction.....................................................................................4
Purpose....................................................................................................................................... 4
Scope.......................................................................................................................................... 4
Proposed Changes...................................................................................................................... 4

2.

Current Employee Data Security...................................................5

Cost Center/AMEX Security Code/Org Security Tree..................................................................5
Department ID/People Leader Indicator......................................................................................7
Supervisor ID Update Process..................................................................................................... 8

3.

PS 9.1 Re-implementation Initiative..............................................9

Fit-gap Analysis........................................................................................................................... 9
PS 9 Row Level Security............................................................................................................. 9

4.

Future Employee Data Security...................................................10

Security Sets.............................................................................................................................. 11
Security Access Type................................................................................................................. 12
Department ID and Department Table.......................................................................................13
Department Security Tree (DEPT_SECURITY).........................................................................15
Security by Department Tree..................................................................................................... 16
Security by Permission List........................................................................................................ 17
Security Join Table for Row Level Security (SJT_CLASS_ALL)................................................18
User Profile and Row Security Permission List..........................................................................21
User Profile and Data Permission List.......................................................................................22
Search Records Where SQL.................................................................................................... 24
Security Join Table for Users and Row Security Class (SJT_OPR_CLS)..................................26
Transaction Security Join Table (SJT_PERSON)......................................................................27
Job Data Component Search View............................................................................................ 29
Prototype Analysis - Summary................................................................................................... 31

1. Introduction
Purpose
The purpose of this document is to provide details of employee data security as implemented in current
version of PS and future employee data security proposal based on the requirements for HR/RL and
privileged users to view data for given People Leader or Department Hierarchy.

Scope
Initial scope of this prototype is to demonstrate new features of employee data security as available in PS 9
and perform proof of concept using People Leader or Department hierarchy with Department Security tree.

Proposed Changes
Changes to this document can be made at any time by completing the revision history table located at the
beginning of this document. A new version should be provided for this document for each modification made
following a review and a summary of the changes should be provided in the Revision column. This document
should be renamed to reflect the new version number at the end of the file name.

2. Current Employee Data Security

Cost Center/AMEX Security Code/Org Security Tree
In current version of PS, Cost Center is one of the data element stored at employee level to capture financial
structure (identifier) for every employee in an Organization. This is a custom field (HRO_COST_CENTER)
stored in JOB record of PS. This identifier also drives other data elements of JOB record like Business Unit,
Company (and Paygroup) etc. This field is mandatory for all employees and for some market like US, it also
has been validated against Account Code and required data integrity is being maintained for every employee.
Following are key data elements being associated with Cost Center field,

Company
Division
Business Unit
Line of Business (Unit Code)
Benefit Routing Code
AMEX Security Code (SCode)

Cost Center Setup Page (HRO Core Setup HRO Cost Center)

AMEX Security Code gets derived based on Country of Company (Regulatory Region), Division, Business
Unit and in some cases based on Line of Business (Unit Code) and Company itself. Based on SCode, a
custom security tree (ORG_SECURITY) has been build to derive the employee data security for PeopleSoft
Users like HR (Human Resource Managers), RL (Relationship Managers) and any other users, who would
require access to PS Queries or core components like Personal Data, Job Data etc.

ORG_SECURITY Tree (Tree Manager Tree Manager ORG_SECURITY)

Organization Security tree has been maintained regularly with any changes to Cost Center attributes. Users
have been provided access to required tree node based on their span of control in an Organization. This
access to users has been provided using custom page where Row Security Class has been given access to
individual tree node.
Access to AMEX Security Code (Setup HRMS Security Setup Security Access)

Assignment of Cost Center to Employee (Workforce Administration Job Information Job

Data)

All search views have been changed based on Org Security tree hierarchy. Query Security views are based
on Fast Security tables, which have been populated using Org Security tree hierarchy. Reports being
developed for HR/RL have been built based on this security structure.

Department ID/People Leader Indicator

In current version of PS, Department ID field has been used to capture Organizational hierarchy between
employee and People Leader (Supervisor ID/Manager ID). Every employee in an organization has been
associated with one department. People Leader gets assigned to department, which they manage and
employee reports to those People Leader gets assigned to same departments.
People Leader Indicator is a custom field stored in JOB record, which indicates if an employee is People
Leader or not. Employee with People Leader Indicator value of Y considered as manager of corresponding
Department it has been assigned to in JOB record.
In current version, Department Security tree has not been implemented but hierarchy between Departments is
being maintained in Department Table itself. A custom field Reports to Department ID has been added to
Department table to maintain relationship between departments and hierarchy gets determined dynamically
based on parent child relationship.

Supervisor ID Update Process

This is a custom process, which maintains relationship between Employee and People Leader in case of
transfers, terminations, new hires, rehires, leave of absence and mass change in organizational structure.
This process makes sure employee and people leader hierarchy gets maintained all the time automatically
with all above-mentioned changes. This process also maintains consistency between Department table and
Job table for People Leaders, so that employees with People Leader indicators are updated as Manager ID in
Department table. This is the first process, which gets executed on nightly basis everyday in production.
Department Table (Setup HRMS Foundation Tables Organization Departments)

3. PS 9.1 Re-implementation Initiative

Fit-gap Analysis
As part of PS 9.1 Re-implementation initiative, it has been determined that Employee Data Security for HR/RL
will be based on People Leader or Department hierarchy instead of current Cost Center/AMEX Security Code
based Org Security hierarchy. In all practical scenarios, HR/RL supports People Leader and their hierarchy,
which in return implies to Department ID of People Leader and hierarchy based on these Department IDs. PS
delivered Department Security tree will be used for this purpose, which would eliminate Parent Department
ID customization on Department Table and would require a process to build and maintain PS delivered
DEPT_SECURITY tree.
At the same time, Employee ID/Supervisor ID relationship for People Leader Self Service transactions using
Direct Reports Setup configuration will be used as it has been used in current version of PS. Department ID,
People Leader Indicator and Supervisor ID update process has been implemented to automate the hierarchy
of employee and people leader for various scenarios as explained in Supervisor ID Update Process section.
There are delivered solutions available from PS/Oracle on this automated process and will be used in future
as well with some changes to support Department Security tree.

PS 9 Row Level Security

Since PS HCMS 9.1 has not been released yet, prototype for Employee Data Security has been performed
using PeopleSoft HCMS 9.0 version. Once PS 9.1 is released, features of Row Level Security will be
analyzed further for any new enhancements.
PeopleSoft HCMS 9.0 provides enhancements to the setup, use, and flexibility of row level security. The
major enhancements to row level security for 9.0 are,
The ability to secure access to job department data, in addition to person data.
The ability to use more than one-way of securing your data.
Easier setup and changeability.
Better performance and flexibility for refreshing security tables.
Real-time updates to security tables.
Easier setup of global and additional appointment security.
More specific details have been explained in Future Employee Data Security section with respect to AMEX
requirements.

4. Future Employee Data Security

Based on requirement for HR, RL and Privileged Users access to Employee Data, a prototype for employee
data security has been built using PS 9 demo environment.
Following high level tasks have been performed to build this prototype,

Configure Security Access Type of Job Department Tree and Security Set as People with Jobs

Multiple Business Units and a SetID (AMEX) has been created to support the prototype.

Few existing Department IDs have been created using Department Table Setup page

Built Department Security Tree based on current hierarchy of Departments (Security IDs)

Assigned Department IDs to Employees in Job Data Component

Created and Assigned Row Security Class and Data Permission Lists to PS Users

Assigned Department IDs to newly created Row Security Class

Assigned Regulatory Region to Data Permission Lists to exclude Employee Data

Execute multiple processes to populate Security Join Tables

Verified access to employee data for a user based on Row Security Class and Data Permission List
access

Additional changes have been performed to Security Search Records to exclude specific Regulatory
Region Employees

10

Security Sets
For employee data security, we will use PS delivered Security Set of PPLJOB (People with Jobs). This
defines the set of Security Access Types that are used to provide access to People with Jobs. These are
Employees, Contingent Workers, and some of the Person of Interest Types.
Security Sets (Setup HRMS Core Row Level Security Security Sets)

11

Security Access Type

For employee data security, we will use PS delivered Security Access Type of 001 (Job Department Tree) and
005 (Job Regulatory Region). These security access types are tied to security set of PPLJOB (People with
Jobs) and uses Department Security tree and Transaction Security Join table as SJT_PERSON.
Security Access Type (Setup HRMS Core Row Level Security Security Access Type)

12

Department ID and Department Table

Department ID gets stored in Department Table. This table will be used as core table for Department Security
Tree. Tree will maintain the hierarchy while Department table will be used to store details about Department
ID and other attributes like description and Manager ID. All Department IDs will be stored with SetID value of
AMEX. In current version of PS, Department IDs are getting stored in Department Table and there are no
changes in process to do so except custom field Parent Department ID will be removed as part of PS 9.1 Reimplementation and Department Security Tree will be maintained to support the actual hierarchy.
Department Table (Set Up HRMS Foundation Tables Organization Departments)

Attached file shows list of Department IDs being created for the prototype. Employees have been assigned to
these corresponding Department IDs in JOB record using Job Data page.

List of Employees for

Employee Data Security Prototype.xls

13

Job Data (Workforce Administration Job Information Job Data)

14

Department Security Tree (DEPT_SECURITY)

This is PS delivered security tree, which can be used by an Organization based on business requirement.
Based on Department Table, Department Security Tree (DEPT_SECURITY) has been built. In current version
of PS, Department Security tree has not been maintained and hierarchy between different Departments have
been maintained by using custom field Parent Department ID, which is part of Department table and value
gets stored for every Departments.
In example shown below a sample hierarchy has been created under top level Department ID. This hierarchy
will be maintained using Tree Manager manually upon implementation.

15

Security by Department Tree

Setup the Department Security for a Row Security Class using the Department Security Trees. In this
example, Row Security Class AMXROWSECCLASS1 has been created to provide access to all employees
under hierarchy of Human Resources Department ID S0000580. Users with access to this Row Security
Class will be able to view all employees from Human Resources Department ID.
Security by Dept Tree (Setup HRMS Security Core Row Level Security Security by Dept Tree)

Data entered in above page gets stored in SCRTY_TBL_DEPT record.

SELECT *
FROM PS_SCRTY_TBL_DEPT
WHERE ROWSECCLASS LIKE 'AMX%'
ROWSECCLASS
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXROWSECCLASS4

SETID
AMEX
AMEX
AMEX
AMEX
AMEX

DEPTID
S000580
S000586
S000000
S000000
S000579

ACCESS_CD
Y
Y
Y
Y
N

TREE_EFFDT
1/1/2009
1/1/2009
1/1/2009
1/1/2009
1/1/2009

TREE_NODE_NUM
1003906250
1001953125
1
1
1250000000

TREE_NODE_NUM_END
1007812499
1003906249
2000000000
2000000000
1499999999

16

Security by Permission List

This option will be used to setup security by access type other than Department Security tree. For prototype,
we will be using Regulatory Region as additional data element to setup security. One can define multiple
Regulatory Regions while setting up Security by Permission List.
Security by Permission List (Setup HRMS Security Core Row Level Security Security by
Permission List)

Data entered in above page gets stored in SJT_CLASS record.

SELECT *
FROM PS_SJT_CLASS
WHERE CLASSID LIKE 'AMX%'
CLASSID
AMXDATAPERMISSIONLIST1

SCRTY_SET_CD
PPLJOB

SCRTY_TYPE_CD
005

SCRTY_KEY1
DEU

SCRTY_KEY2

SCRTY_KEY3

17

Security Join Table for Row Level Security (SJT_CLASS_ALL)

Once Security by Department Tree table has been populated with required access for Row Security Class,
corresponding Security Join Table will be populated using Refresh Row Security Operator process
(SCRTY_CLSUPD). This is PS delivered Application Engine process, which populates SJT_CLASS_ALL table
for every Row Security Class, which have been provided access to required node on Department Security
Tree and any other data element access, which has been provided using Data Permission List. When this
process gets executed, all the DEPTIDs that are at and below the department node defined in the
SCRTY_TBL_DEPT table are included unless the DEPTID exists in the SCRTY_TBL_DEPT with an
ACCESS_CD of No Access.
Refresh Row Security Operator Setup HRMS Core Row Level Security Refresh SJT_CLASS_ALL

Once process gets executed successfully, it populates SJT_CLASS_ALL record with Department IDs, which
are in span of control for Department node defined Security by Department Tree page and data element
defined for Data Permission List. In below example, data has been populated for different Row Security
Classes and Data Permission List defined for prototype.
In summary, this table creates normalized security table based on access being provided to Row Security
Class and/or Data Permission List and used as driving table to determine employee data security for users.
SELECT *
FROM PS_SJT_CLASS_ALL
WHERE CLASSID LIKE 'AMX%'

18

CLASSID
AMXDATAPERMISSIONLIST1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4

SCRTY_SET_CD
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB

SCRTY_TYPE_CD
005
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001
001

SCRTY_KEY1
DEU
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX

SCRTY_KEY2
S000580
S001131
S001934
S003695
S007808
S015466
S020003
S021966
S024578
S000586
S002662
S007811
S018179
S018423
S022368
S023719
S027536
S000000
S000001
S000577
S000579
S000580
S000581
S000582
S000583
S000586
S000587
S000588
S001131
S001934
S002662
S003695
S007808
S007811
S015466
S018179
S018423
S020003
S021966
S022368
S023719
S024578
S027536
S000000
S000001
S000577
S000580
S000581
S000582
S000583
S000586
S000587
S000588
S001131

SCRTY_KEY3

TREE
N
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y

19

CLASSID
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4
AMXROWSECCLASS4

SCRTY_SET_CD
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB
PPLJOB

SCRTY_TYPE_CD
001
001
001
001
001
001
001
001
001
001
001
001
001
001

SCRTY_KEY1
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX
AMEX

SCRTY_KEY2
S001934
S002662
S003695
S007808
S007811
S015466
S018179
S018423
S020003
S021966
S022368
S023719
S024578
S027536

SCRTY_KEY3

TREE
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y
Y

20

User Profile and Row Security Permission List

From PS 8.9 version onwards, Row Security Permission List should be used for Employee Data Security
based on Department Security Tree. For other access type based on JOB data elements like Location,
Regulatory Region, Business Unit, Grade etc. Data Permission List will be used, which will be assigned to PS
Roles and corresponding Roles will be assigned to the users.
Every PS User will require PS User ID to login to Application. This User ID will be assigned to Row Security
Permission List based on their access to employees of certain Department or People Leader in an
organization. For example, User AMXUSER1 has access to Department ID of Human Resource (S000580).
In this case Row Security Class (AMXROWSECCLASS1) being created for this combination will be assigned
to that User through User Profile page as shown below.
User Profiles (PeopleTools Security User Profiles)

Information entered on above-mentioned page gets populated to PSOPRDEFN record of PS.

SELECT OPRID, ROWSECCLASS
FROM PSOPRDEFN
WHERE OPRID LIKE 'AMX%'
OPRID
AMXUSER1
AMXUSER2
AMXUSER3
AMXUSER4
AMXUSER5

ROWSECCLASS
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXROWSECCLASS1

21

User Profile and Data Permission List

With PS 8.9 onwards, PS Roles and Permission Lists can also be used to determine Employee Data Security.
For Data Permission List, access will be provided using Security by Permission List page. Once defined and
assigned to Roles, Roles will be attached to users similarly to any other Roles, which will be assigned to
users for menu level access.
For prototype, Role AMXDATASECURITY1 has been created and assigned to user AMXUSER5. This Role
has been attached with Permission List AMXDATAPERMISSIONLIST1, which has been provided access to
Access Type of Regulatory Region DEU (Germany) as shown under Security by Permission List section.
User Profiles (PeopleTools Security User Profiles Roles)

User AMXUSER5 has been assigned to Row Security Class of AMXROWSECCLASS3, which has been give
access to Employees under top level Department ID (S000000) and Data Permission List of
AMXDATASECURITY1, which has been given access to all employees from Germany (DEU) Regulatory
Region.

22

PS delivered search records would provide access of all Employees (including Germany) for user
AMXUSER5 based on access to Row Security Class and Data Permission List. But one of the requirements
is to exclude access of Germany employees for certain group of HR/RL and privileged users. To take care of
this requirement search records will be changed in such a way that instead of using Data Permission List
security for Regulatory Region as inclusion criteria, it will be used as exclusion criteria. This will be done by
changing Where condition of search records, which would considered as customization from PS delivered
code and this has been explained in Red Paper Row Level Security 89 on page number 186 onwards,
published by PS/Oracle.

Row Level Security

89.pdf

23

Search Records Where SQL

For prototype purpose, search records like PERS_SRCH_GBL, EMPLMT_SRCH_GBL
EMPLMT_SRCH_COR have been changed. Below is SQL definition for PERS_SRCH_GBL,

and

SELECT DISTINCT %Sql(SCRTY_SEL_PKEY, OPR,SEC)

, %Sql(SCRTY_SEL_CORSBR,NM,SEC)
, %Sql(SCRTY_SEL_FLDSBR,SEC)
FROM %Sql(SCRTY_PER_NM_FROM)
WHERE %Sql(SCRTY_NO_APPT1)
AND %Sql(SCRTY_NAME)
AND %Sql(SCRTY_WHERE, 'PPLJOB')
As part of customization, SQL definition SCRTY_WHERE will be changed to use access type Regulatory
Region as exclusion criteria instead of delivered inclusion criteria. For this purpose, SQL SCRTY_WHERE will
be saved as SCRTY_WHERE_CUST and changes will be performed to that SQL definition instead of
delivered by PS/Oracle.
Here is the SQL definition of SCRTY_WHERE_CUST and portion highlighted in yellow color will be added as
customization to meet the requirements for exclusion of Regulatory Region.
(EXISTS (
SELECT 'X'
FROM PS_SJT_CLASS_ALL CLS
, PS_SJT_OPR_CLS SOC
WHERE CLS.SCRTY_SET_CD = %P(1)
AND CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD
AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1
AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2
AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3
AND CLS.TREE = 'Y'
AND SOC.OPRID=OPR.OPRID
AND SOC.CLASSID = CLS.CLASSID
AND SOC.CLASSID = OPR.ROWSECCLASS
AND SOC.SEC_RSC_FLG = '1' )
OR EXISTS (
SELECT 'X'
FROM PS_SJT_CLASS_ALL CLS
, PS_SJT_OPR_CLS SOC
WHERE CLS.SCRTY_SET_CD = %P(1)
AND CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD
AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1
AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2
AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3
AND CLS.TREE = 'N'
AND SOC.OPRID=OPR.OPRID
AND SOC.CLASSID = CLS.CLASSID )
OR EXISTS (
SELECT 'X'
FROM PS_SJT_CLASS_ALL CLS
, PS_SJT_OPR_CLS SOC
WHERE CLS.SCRTY_SET_CD = %P(1)
AND CLS.SCRTY_TYPE_CD = SEC.SCRTY_TYPE_CD
AND CLS.SCRTY_KEY1 = SEC.SCRTY_KEY1

24

AND CLS.SCRTY_KEY2 = SEC.SCRTY_KEY2

AND CLS.SCRTY_KEY3 = SEC.SCRTY_KEY3
AND CLS.TREE = 'Y'
AND SOC.OPRID=OPR.OPRID
AND SOC.CLASSID = CLS.CLASSID
AND SOC.CLASSID = OPR.ROWSECCLASS
AND SOC.SEC_RSC_FLG = '3' ))
AND NOT EXISTS (
SELECT 'X'
FROM PS_SJT_CLASS_ALL CLS
, PS_SJT_OPR_CLS SOC
, PS_SJT_PERSON SEC2
WHERE CLS.SCRTY_SET_CD = 'PPLJOB'
AND CLS.SCRTY_TYPE_CD = '005'
AND CLS.TREE = 'N'
AND SOC.OPRID = OPR.OPRID
AND SOC.CLASSID = CLS.CLASSID
AND SEC2.SCRTY_TYPE_CD = CLS.SCRTY_TYPE_CD
AND SEC2.SCRTY_KEY1 = CLS.SCRTY_KEY1
AND SEC2.SCRTY_KEY2 = CLS.SCRTY_KEY2
AND SEC2.SCRTY_KEY3 = CLS.SCRTY_KEY3
AND SEC2.EMPLID = SEC.EMPLID
AND SEC2.EMPL_RCD = SEC.EMPL_RCD
AND SEC2.SETID_DEPT = SEC.SETID_DEPT
AND SEC2.DEPTID = SEC.DEPTID)
Once above changes have been made, PER_SRCH_GBL or all other search records where PPLJOB has
been used, view definition will be changed for Where condition as highlighted below.
SELECT DISTINCT %Sql(SCRTY_SEL_PKEY, OPR,SEC)
, %Sql(SCRTY_SEL_CORSBR,NM,SEC)
, %Sql(SCRTY_SEL_FLDSBR,SEC)
FROM %Sql(SCRTY_PER_NM_FROM)
WHERE %Sql(SCRTY_NO_APPT1)
AND %Sql(SCRTY_NAME)
AND %Sql(SCRTY_WHERE_CUST, 'PPLJOB')

25

Security Join Table for Users and Row Security Class

(SJT_OPR_CLS)
SJT_OPR_CLS is the security join table for operator security data and contains the OPRID and all of its
security classes. Once PS Users have been assigned to Row Security Class, this table gets populated by
using PS delivered process - Refresh the SJT_OPR_CLS Security Join Table (SCRTY_OPRCLS).
Refresh Security Join Table for Users (Setup HRMS Core Row Level Security Refresh
SJT_OPR_CLS)

Once process gets executed successfully, it populates SJT_OPR_CLS record with User ID and corresponding
Row Security Class and/or Data Permission Lists. For prototype, 5 different users have been created with
different Row Security Class and Data Permission List. SQL below would show corresponding Row Security
Class and/or Data Permission List for these User IDs.
SELECT *
FROM PS_SJT_OPR_CLS
WHERE OPRID LIKE 'AMX%'
OPRID
AMXUSER1
AMXUSER2
AMXUSER3
AMXUSER4
AMXUSER5
AMXUSER5

CLASSID
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXDATAPERMISSIONLIST1
AMXROWSECCLASS3

SEC_RSC_FLG
1
1
1
1
2
1

26

Transaction Security Join Table (SJT_PERSON)

SJT_PERSON is the security join table for the person transactional data. This table is updated from JOB,
PER_POI_TYPE, PER_POI_SCRTY, and PERS_NID. It contains the data for the PPLJOB and PPLPOI
security sets. This table gets populated by PS delivered process Refresh Trans. SJT Tables
(SCRTY_SJTUPD).
Refresh Trans. SJT Tables (Setup HRMS Security Core Row Level Security Refresh Trans.
SJT Tables)

For this prototype, we have used PS delivered Security Access Type of 001 (Job Department Tree) and
Access Type of 005 (Job Regulatory Region), which are tied to security set of PPLJOB (People with Jobs).
Based on this setting, SJT_PERSON table gets populated for every employee with corresponding security
keys. In this case Security Type Code is 001 (Job Department Tree), First Security Key is AMEX (SetID value
of Department ID) and Second Security Key is Department IDs as available on Department Security Tree.
Attached excel file shows list of employees gets populated to SJT_PERSON record based on abovementioned key structure.

List of Employees in
SJ T_PERSON.xls

27

This table also gets populated by PS delivered process Nightly SJT Update ( SCRTY_SJTDLY).
Nightly SJT Update (Setup HRMS Security Core Row Level Security Nightly SJT Refresh
Process)

28

Job Data Component Search View

When user AMXUSER3 logs into PS and search for an employee using wild character of % for name field
through Job Data component, it returns 49 employees based on Row Security Class access being provided to
that user. All Security Join Tables being populated in earlier section determines the selection of employee list
for the user.
Job Data Search Page (Workforce Administration Job Information Job Data)

29

At the same time when user AMXUSER5 logs into PS and search for an employee using wild character of %
for name field through Job Data component, it returns 42 employees based on Row Security Class (top level
access) and Data Security Permission (exclude Germany Employees) access being provided to that user. All
Security Join Tables being populated in earlier section determines the selection of employee list for the user.
Job Data Search Page (Workforce Administration Job Information Job Data)

30

Prototype Analysis - Summary

Total number of employees used for prototype 49. These employees have been attached Department
IDs, which is part of Department Security Tree of SetID AMEX.
Total number of Departments being created for Department Security Tree - 25
Number of Row Security Classes with corresponding access 4
ROWSECCLASS
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXROWSECCLASS4

SETID
AMEX
AMEX
AMEX
AMEX
AMEX

DEPTID
S000580
S000586
S000000
S000000
S000579

ACCESS_CD
Y
Y
Y
Y
N

TREE_EFFDT
1/1/2009
1/1/2009
1/1/2009
1/1/2009
1/1/2009

TREE_NODE_NUM
1003906250
1001953125
1
1
1250000000

TREE_NODE_NUM_END
1007812499
1003906249
2000000000
2000000000
1499999999

Number of Data Permission List with corresponding access - 1

CLASSID
AMXDATAPERMISSIONLIST1

SCRTY_SET_CD
PPLJOB

SCRTY_TYPE_CD
005

SCRTY_KEY1
DEU

SCRTY_KEY2

SCRTY_KEY3

Number of Users with access to Row Security Class and/or Data Permission List 5
OPRID
AMXUSER1
AMXUSER2
AMXUSER3
AMXUSER4
AMXUSER5
AMXUSER5

CLASSID
AMXROWSECCLASS1
AMXROWSECCLASS2
AMXROWSECCLASS3
AMXROWSECCLASS4
AMXDATAPERMISSIONLIST1
AMXROWSECCLASS3

SEC_RSC_FLG
1
1
1
1
2
1

Count of Employees accessed by every Users based on security access provided to their individual IDs
User ID
AMXUSER1
AMXUSER2
AMXUSER3
AMXUSER4
AMXUSER5

Count of Employees
20
18
49
48
42

31