Portal Content Referrences migration

You could copy Content Reference using Application Designer, but you should me careful when doing this across different applications.
Applications have different parent folders, content reference has permissions that are application specific, which to not have to exist in the target environment.
And especially Portal works different from the other applications.

Portal, said very easily, "has no own application", but is used to link to content references to other applications.
You should really set up Content reference in Portal manually, that's why Unified Navigation was introduced.

Why you should set it up manually and not copy via application designer:
Content reference in for example HCM is usually configured on LOCAL_NODE.
When you copy this across to Portal, Portal will interpret this a link to the Portal application.
This has to be changed in Portal to the local node of HCM, for example PSFT_HR.

Content reference have permissions set, usually deviated from the permission lists on components using the Portal Security Sync process.
Permission to a component is/could be different than permission to the content reference that references the component.
One is, can I see the menu link, other is, do I have access to the page.

And is exactly what you should do with Portal in junction with other PeopleSoft applications.
Portal has only permissionlist to content references (menu links) to components on other Applications nodes.
On the other application permission list on the actual component has to set.

So userprofiles and assigned roles will have to synchronized across applications user the USER_SYNC service.
Roles in Portal and and other applications have to exists, but do not need to have any permissionlists in the Portal environment.
Suppose you have a user in HCM with roles and within the role permissionlist to components.
The same user will be synced to Portal, the user profile will be copied and assigned roles will be copied.
Now Portal needs to have roles/permissionlists to the content references in Portal that link to the HCM component.
These permissionlist in Portal can be other than the ones in HCM.

Portal Security Sync

The portal registry (basically the left-hand menu navigation) is made up of folders that can contain subfolders and/or content references. Content references point to different types of content, but most of the time in your HCM, FSCM or CRM application they point to components.
The portal registry security table is called PSPRSMPERM. This table defines which permission lists and roles are assigned to each folder and content reference.

When you do edit permission lists on-line, PeopleCode keeps PSPRSMPERM in sync. But not so when you migrate permission lists, or when you build or update them via SQL (a technique I’ve grown to depend on).

So if you migrate a new permission list into an environment, how do you get the portal registry synchronized? Well, that’s the job of Portal Security Sync.
Portal security sync can be a confusing process. In this article I’ll try to make some sense of what it is, why it’s necessary, what kinds of issues you can expect, and some alternatives.
Portal Security Sync is an app engine that basically goes through all of your permission lists, grabs the components, and figures out which content references that permission list relates to. Then it updates the content reference with that permission list, and walks up the folder hierarchy updating each parent folder with that permission list as well. The table that gets updated is – you guessed it – PSPRSMPERM. Starting with PeopleTools 8.45 it even removes security from folders and content references that are not valid any more.

The problem is that Portal Security Sync can grant more access than you want. Keep in mind that the portal registry can provide multiple paths to get to the same component. Suppose you have AR, but not Order Management. You might end up with an Order Management folder on your top menu that takes you all the way down to the Dunn and Bradstreet Customer Information page in addition to the normal navigation through the Customers menu. Or you might find that managers and employees share a common component to update employee information, but it appears under both the Employee Self Service Navigation Collection and the Manager Self Service Navigation Collection. Now suppose you don’t want to let employees see a menu item called Manger Self Service. That’s too bad, because portal security sync will put it on everybody’s menu due to a common component four levels down.

I believe in keeping one set of permission lists across all environments. I depend on migrating permission lists to keep them in sync across all of my environments. So that means Portal Security Sync is essential. I have two techniques to keep folders from popping up where I don’t want them.

First, I use the “Hide from Portal Navigation” on folders that we don’t want (that aren’t licensed for instance). For example, in that Order Management example above I’d just pull up the unwanted folder in “Structure and Content” and click the Hide from Portal Navigation button.

 

 

 

Sometimes though you might not want to eliminate the entire navigation path. Consider the example I mentioned earlier where we have a manager self service and an employee self service navigation collection, and we only want people with a manager role to see the manager self service collection. In this case, we must manually remove the unwanted Employee Self Service permission lists from the Folder Security tab of the Manager Self Service folder, and leave the Manager Self Service ones. In reality, I have an SQL script that I run after Portal Security Sync for this purpose. I plan to create an SQR or app engine to do the deletes, and schedule it to run after Portal Security Sync within a PSJob.

One trick about portal security sync I wanted to mention: It needs to be run as a user with the Portal Administrator role. Portal Administrator is a special role which makes every entry in the portal registry show up, regardless of how your permission lists are defined.

Another problem I see from time to time is that after running portal security sync, the changes don’t necessarily show up for the users. If that happens to you, first check the PSPRSMPERM table or look on-line to make sure the content references actually got populated with the correct permission lists. If that looks OK, have the user clear their browser cache (temporary internet files). If that doesn’t work, purge app server cache. If that doesn’t work, try the web server cache.

Granted, Portal Security Sync is a shotgun approach. If you’re only wanting to set up security for a single component, You can run the Component Registration Wizard process in app designer to get ‘er done. If you like living on the edge, check out the following SQLPlus script I’m working on to show what rows should be in PSPRSMPERM, and inserts them without generating unique constraints. I uses Oracle’s Connect By feature to walk up the folder hierarchy, so my apologies to non-Oracle users. If you run it in SQLPlus, it’ll prompt you for a component.

-- Identify the rows that should be inserted into PSPRSMPERM
select DISTINCT AA.PORTAL_NAME, AA.PORTAL_REFTYPE, AA.PORTAL_OBJNAME, CC.CLASSID, 'P'
FROM
(SELECT PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, connect_by_root(A.PORTAL_URI_SEG2) PNLGRPNAME, 'ALLPAGES', 'P', '0'
from (SELECT distinct A.PORTAL_NAME, A.PORTAL_LABEL, A.PORTAL_OBJNAME, a.PORTAL_PRNTOBJNAME,
A.PORTAL_URI_SEG1, A.PORTAL_URI_SEG2, A.PORTAL_URI_SEG3, A.PORTAL_REFTYPE
FROM PSPRSMDEFN A
WHERE
A.portal_name = 'EMPLOYEE' and
A.portal_objname <> A.portal_prntobjname and
not exists (
select 'x'
from PSPRSMSYSATTRVL
where portal_name = A.PORTAL_NAME AND
portal_Reftype = A.PORTAL_REFTYPE and
portal_objname = A.PORTAL_OBJNAME and
PORTAL_ATTR_NAM = 'PORTAL_HIDE_FROM_NAV' and
A.PORTAL_OBJNAME not in ('CO_NAVIGATION_COLLECTIONS', 'PORTAL_BASE_DATA')
)
) A
start with PORTAL_URI_SEG2 = '&1'
connect by prior A.portal_prntobjname = A.portal_objname ) AA, PSMENUITEM BB, PSAUTHITEM CC
WHERE AA.PNLGRPNAME = BB.PNLGRPNAME AND
BB.MENUNAME = CC.MENUNAME AND
BB.BARNAME = CC.BARNAME AND
BB.ITEMNAME = CC.BARITEMNAME
/
-- Update version stuff so the user doesn’t have to clear browser cache after the update
UPDATE PSVERSION SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'SYS'
/
UPDATE PSLOCK SET VERSION = VERSION + 1 WHERE OBJECTTYPENAME = 'PRSM'
/

-- Delete the rows that may already exist so we don’t get unique constraints
DELETE FROM PSPRSMPERM PPERM
WHERE (PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, PORTAL_PERMNAME, PORTAL_PERMTYPE) IN
(select DISTINCT AA.PORTAL_NAME, AA.PORTAL_REFTYPE, AA.PORTAL_OBJNAME, CC.CLASSID, 'P'
FROM
(SELECT PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, connect_by_root(A.PORTAL_URI_SEG2) PNLGRPNAME, 'ALLPAGES', 'P', '0'
from (SELECT distinct A.PORTAL_NAME, A.PORTAL_LABEL, A.PORTAL_OBJNAME, a.PORTAL_PRNTOBJNAME,
A.PORTAL_URI_SEG1, A.PORTAL_URI_SEG2, A.PORTAL_URI_SEG3, A.PORTAL_REFTYPE
FROM PSPRSMDEFN A
WHERE
A.portal_name = 'EMPLOYEE' and
A.portal_objname <> A.portal_prntobjname and
not exists (
select 'x'
from PSPRSMSYSATTRVL
where portal_name = A.PORTAL_NAME AND
portal_Reftype = A.PORTAL_REFTYPE and
portal_objname = A.PORTAL_OBJNAME and
PORTAL_ATTR_NAM = 'PORTAL_HIDE_FROM_NAV' and
A.PORTAL_OBJNAME not in ('CO_NAVIGATION_COLLECTIONS', 'PORTAL_BASE_DATA')
)
) A
start with PORTAL_URI_SEG2 = '&1'
connect by prior A.portal_prntobjname = A.portal_objname ) AA, PSMENUITEM BB, PSAUTHITEM CC
WHERE AA.PNLGRPNAME = BB.PNLGRPNAME AND
BB.MENUNAME = CC.MENUNAME AND
BB.BARNAME = CC.BARNAME AND
BB.ITEMNAME = CC.BARITEMNAME
)
/
-- Now insert the new Portal Registry Rows
insert into PSPRSMPERM (PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, PORTAL_PERMNAME, PORTAL_PERMTYPE, PORTAL_ISCASCADE)
(select DISTINCT AA.PORTAL_NAME, AA.PORTAL_REFTYPE, AA.PORTAL_OBJNAME, CC.CLASSID, 'P', '0'
FROM
(SELECT PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, connect_by_root(A.PORTAL_URI_SEG2) PNLGRPNAME, 'ALLPAGES', 'P', '0'
from (SELECT distinct A.PORTAL_NAME, A.PORTAL_LABEL, A.PORTAL_OBJNAME, a.PORTAL_PRNTOBJNAME,
A.PORTAL_URI_SEG1, A.PORTAL_URI_SEG2, A.PORTAL_URI_SEG3, A.PORTAL_REFTYPE
FROM PSPRSMDEFN A
WHERE
A.portal_name = 'EMPLOYEE' and
A.portal_objname <> A.portal_prntobjname and
not exists (
select 'x'
from PSPRSMSYSATTRVL
where portal_name = A.PORTAL_NAME AND
portal_Reftype = A.PORTAL_REFTYPE and
portal_objname = A.PORTAL_OBJNAME and
PORTAL_ATTR_NAM = 'PORTAL_HIDE_FROM_NAV' and
A.PORTAL_OBJNAME not in ('CO_NAVIGATION_COLLECTIONS', 'PORTAL_BASE_DATA')
)
) A
start with PORTAL_URI_SEG2 = '&1'
connect by prior A.portal_prntobjname = A.portal_objname ) AA, PSMENUITEM BB, PSAUTHITEM CC
WHERE AA.PNLGRPNAME = BB.PNLGRPNAME AND
BB.MENUNAME = CC.MENUNAME AND
BB.BARNAME = CC.BARNAME AND
BB.ITEMNAME = CC.BARITEMNAME
)
/
--Update the version stuff which should keep users from having to clear browser cache
UPDATE PSPRSMDEFN
SET VERSION = (SELECT VERSION FROM PSLOCK WHERE OBJECTTYPENAME = 'PRSM'),
LASTUPDDTTM=SYSDATE
WHERE (PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME) IN
(select DISTINCT AA.PORTAL_NAME, AA.PORTAL_REFTYPE, AA.PORTAL_OBJNAME
FROM
(SELECT PORTAL_NAME, PORTAL_REFTYPE, PORTAL_OBJNAME, connect_by_root(A.PORTAL_URI_SEG2) PNLGRPNAME, 'ALLPAGES', 'P', '0'
from (SELECT distinct A.PORTAL_NAME, A.PORTAL_LABEL, A.PORTAL_OBJNAME, a.PORTAL_PRNTOBJNAME,
A.PORTAL_URI_SEG1, A.PORTAL_URI_SEG2, A.PORTAL_URI_SEG3, A.PORTAL_REFTYPE
FROM PSPRSMDEFN A
WHERE
A.portal_name = 'EMPLOYEE' and
A.portal_objname <> A.portal_prntobjname and
not exists (
select 'x'
from PSPRSMSYSATTRVL
where portal_name = A.PORTAL_NAME AND
portal_Reftype = A.PORTAL_REFTYPE and
portal_objname = A.PORTAL_OBJNAME and
PORTAL_ATTR_NAM = 'PORTAL_HIDE_FROM_NAV' and
A.PORTAL_OBJNAME not in ('CO_NAVIGATION_COLLECTIONS', 'PORTAL_BASE_DATA')
)
) A
start with PORTAL_URI_SEG2 = '&1'
connect by prior A.portal_prntobjname = A.portal_objname ) AA
)
/
-- Un-define our &1 variable so it’ll prompt again the next time the script is run
UNDEF 1

Enterprise Learning within HCM vs ELM Stand-Alone

PeopleSoft clients often ask about implementing the ELM module – which stands for Enterprise Learning Management. Giving them an answer is not that simple because there are two products with the same name. I then have to ask “Which ELM do you mean?”

1.     Enterprise Learning – which is part of the HCM suite and used to be called ‘Training Administration’ and referred to by Oracle as “Enterprise Learning Management” within their own documentation

2.     Enterprise Learning Management – a stand-alone module that incorporates components of the HCM functionality but does a lot more

When you license the HCM suite and/or the ELM product, you need to be sure of what you are buying. Hopefully, the following description will help you understand the difference.

Enterprise Learning within HCM

For HCM users, whose main concern is with employee training, the Enterprise Learning module found in the HCM suite is likely all that you will need. It can do the following and more:

§  Define training courses

§  Track employee completion of training courses

§  Manage training class schedules and enrollment

§  Print class rosters and materials

§  Allow employees and managers to request training and enroll on-line with waitlists if class is full

§  Define training programs – curriculum that can be attached to certain jobs and certifications

§  Define training course pre-requisites

§  Define training budgets – by department (note: does not work with financial system)

§  Track all aspects of training classes such as instructors and their qualifications, equipment, classrooms, books, etc.

§  Tie training to competencies and employee goals for performance reviews

§  Track employee testing

§  Enable students to give feedback on training through evaluations

§  Perform analysis on training costs

You can get as elaborate as you wish, but you can also do just the first two items on the above list. The simple approach is to record employee training and completion date of courses.

If you want to implement Enterprise Learning and are overwhelmed by the size of the effort or the long list of functionality and features, I suggest you start with the first two. You can use the list of courses and employee training history to build on when you’re ready for more and there will be no re-work or wasted effort.

ELM Stand-Alone (HCM sold separately – batteries not included)

The Stand-Alone version of ELM does everything the HCM version does but is more student focused. This module allows not only managing courses and class schedules but also the ability to have students launch on-line courses and web-casts, take tests on-line and integrate with external training delivery methods to make a complete training delivery system to go beyond employee training management.

It is the integration with training delivery tools that makes this version different from the module embedded in the HCM product suite. Other software may be required based on your needs.

Understanding Your Requirements

Before exploring the implementation of Enterprise Learning in any form, ask yourself these basic questions:

§  Do we want a tool to conduct training or track training history?

§  If the answer is ‘conduct training’ then the stand-alone ELM is what you want.

§  If the answer is ‘track training’ and you own the HCM version that is what you want.

§  Do we want to train employees or customers?

§  If ‘customers’ then the stand-alone ELM product is what you want.

§  If ‘employees’ then most likely the HCM version will suffice.

§  Do we want to simply track training history or set up class schedules and have employees and managers enroll on-line? Basically ‘Track’ training vs. ‘Manage’ training.

§  Both answers mean the HCM product will do the job but the extent of the implementation effort and day-to-day maintenance will be a bit larger for managing training rather than just tracking.

§  Do we want training information integrated with performance and profile modules?

If the answer is yes, you are already HCM customers and want training reflected in employee data, goals and performance monitoring. This also makes the implementation effort a bit larger but the good news is that Oracle has made this integration easier in recent versions.

HCM Data Regulations

PeopleSoft HCM Data Regulated using the below setup information.
Business Units
Table Sets
Set ids
Record Groups
Business Unit Option Defaults
Org Defaults by Permission List

Now we will look at each item and try to understand what they meant to the organization.
Business Unit:

Set Up HRMS, Foundation Tables, Organization, Business Unit, Business Unit 

You create business units  to track and report specific business information.For HCM, you must establish at least one business unit.
If your organization uses same processing rules , it make sense to have a single business unit; if you use different rules in different companies, countries, or functional areas, you may choose to create multiple business units.

Example : Banking treats each branch as a business unit, which means that the bank could do reporting for its people within each branch.


Tableset sharing:

Sharing rows of data in a tableset across business units or limiting rows to a single business unit.

Before you set up tableset controls setup Business Unit, Setid and Record Groups.

Understanding Table Set:
Table Set ID:
setID:
PeopleTools, Utilities, Administration, TableSet Ids
Use the above page to setup Logical SetID.
A set of data rows in a control table that is identified by the same high level key.

The highlevel key that identifies a set of data rows. There are two types of setIDs:

• Physical SetIDs
  The setID of a business unit (BUSINESS_UNIT = SETID). The rows of data in a physical setID have a one to one relationship with the business unit.
• Logical SetID
  A logical setID that is generic and determined by business rules other than business unit. Logical setIDs enable you to share rows of data across multiple business units.

Record Groups:
PeopleTools, Utilities, Administration, Record Group

Record Group is a group of records which will be shared by Setid across business units.You can make Record Group to be use of default Setid on this page, else it will be assigned using Table Set Control with group of Record Groups.

Table Set Control:
PeopleTools, Utilities, Administration, Table Set Control
Assigning Group of Record Groups to a Setid using a Set Control Value which could be business unit, country, reg region ...etc.

Example : When you give XXX as business unit on Job data page, it will pull the record groups for the set control value XXX and gets the list of all the departments or job codes from the record group corresponding to the Setid used on the set control page.

Org Defaults by Permission List:
Set Up HRMS, Foundation Tables, Organization, Org Defaults by Permission Lst, Defaults

On the Org Defaults by Permission List component (OPR_DEF_TBL_HR) set up primary permission lists with: Default values for the following fields: Business Unit, SetID,Company,Country,Regulatory Region, To Currency, Currency Rate Type.

Business Unit Option Defaults:
Set Up HRMS, Foundation Tables, Organization, Business Unit Options Defaults, Business Unit Options Defaults
When users access an HCM component, the system populates some of the fields, such as business unit, company, and country using the values you associated with the user's primary permission list. You can also associate default values with setIDs on the Business Unit Options Defaults page (BUS_UNIT_OPT_HR).

To set up business unit defaulting:
On the Tableset Control – Record Group page (SET_CNTRL_TABLE1), select the SetID that controls business unit defaulting for this business unit.

1. This enables you to share defaulting rules across business units.
   
2. Enter the setID's default values on the Business Unit Options Defaults component. 

Hope this gives fair understanding on Data Regulations using Business Unit, Set id and Table Set Sharing.

Row Level Security

Restricting Data to the Persons who are not authorized to see and also providing access to the data who are authorized to see data is called Data Security.
Row Level Security Prevents the user from being able to access data they are not allowed via the search page.

Security Installation Settings :
Set Up HRMS, Security, Core Row Level Security, Security Installation Settings
Settings are Include Home/Host, Include Additional Assignments, Job Actions that Trigger Future Dated Security Rows.

Security Sets:
Set Up HRMS, Security, Core Row Level Security, Security Sets
Defining what data to be Secured
    Security Set Table :
Transaction Sec. Join Table : Transaction Tables like SJT_PERSON, SJT_DEPT..etc
SJT Temp Table : Temporary table that is used during the SCRTY_SJTUPD Application Engine process that refreshes the transaction security join table. This table must be a copy of the Transaction Sec Join Table along with the PROCESS_INSTANCE field.
SQLID for Value Field List : SQLID of the SQL object that contains a list of the fieldnames found in the transaction security join record. This SQL is used in the App Engine Process SCRTY_SJTUPD when the transaction security join record is refreshed.
Security Access Types for this Set : This is a read-only grid that displays all of the security types that have been created for this security set and indicates which ones have been enabled

   Security Update Groups:
Groupings of data can be selected for refresh on the Refresh Trans.This allows the process to be run for just a subset of data in the SJT instead of having to refresh the entire table.


Security Type :
Set Up HRMS, Security, Core Row Level Security, Security Types
Defining How the data is secured
  Security Type Table :
Enabled :  Enable or Disable of the Security Type
Include Future Dates : Future Dated Actions can be viewed by the persons for the actions specified on the Security Installation component (Not only job, other records having future dated can be handled)
Use Department Security Tree : Check box indicates that the security access type is based on a department security tree
Transaction Table : Transaction record that contains the attribute that this security type is based on. In this case, it is the Department ID in the JOB record.
Security Keys : Provide the keys based on that data secured.Security Key1, Security Key2, Security Key3, Prompt Rec for Sec Key1,Prompt Rec for Sec Key2 and Prompt Rec for Sec Key3.
If the field is a translate value then a view must be created to return those translate values.

Special Job Security Versions : System only displays this group box when the transaction record is JOB. The fields shown will depend on which of these have been enabled on the Security Installation Settings component

   Security Type SQL:
SQLID's for the SQL objects used in the Application Engine program SCRTY_SJTUPD for refreshing the transaction SJT.

Security by Department :
1)Create the Department Security Tree
2)Create permission list
PeopleTools, Security, Permissions & Roles, and Permission Lists
3)Assign Departments to the Permission List
Set Up HRMS: Security: Core Row Level Security: Security by Dept Tree

4)Refresh the SJT_CLASS_ALL process
Set Up HRMS: Security: Core Row Level Security: Refresh SJT_CLASS_ALL

5)Assign the row security permission list on the User Profile General Page
PeopleTools, Security, User Pofiles, User Pofiles, General


Security by Permission List:

Use the Security by Permission List component for all security types that are not based on a department security tree.

1) Create Permission List
PeopleTools, Security, Permissions & Roles, and Permission Lists
2) Set up Security Set, Security Access Type and Keys
Set Up HRMS, Security, Coe Row Level Security, Security by Permission List
3) Group the Permission Lists into One Role
PeopleTools, Security, Permissions & Roles, Roles
4) Assign Roles to the Users using User Profile, Roles Page
5) Refresh SJT_CLASS_ALL, SJT_OPR_CLS and Refresh SJT Trans Process.

Nightly SJT Refresh Process to handle the future dated transactions. i.e when future dated transactions become active, it will delete the previous current data.

 Security Data Inquiry
Set Up HRMS, Security Core Row Level Security, Security Data Inquiry
This component is very useful for testing the Row Level Security after implementing and also very helpful in debugging issues.

Person Model

Person Model is an effective way of tracking employee, Contingent Worker and Person Of Interest in the Organization based on the Organizational/Employee Instance, Assignments with (Employee, Contingent Worker) and without (Person Of Interest) job information .

let us understand important Fields from Person Model.
PER_ORG : How a person is related to the organization (EMP - Employee, CWR - Contingent Worker, POI - Person Of Interest)
ORG_INSTANCE_ERN : How Many Employement Instances a person is having in the Organization.Each Employee Instance should have minimum of one Assignment
EMPL_RCD : How Many Job Assignments a person is having for a Employement Instance in the organization.
POI_TYPE : Person Of Interest Type (Un Known, External Trainer ..etc). Base table to store different Types  is PS_POI_TYPE_TBL, which can be configured going through the navigation Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.

let us understand Important Records from Person Model
PS_PERSON : Every person you enter in the system will have one record in PERSON.Contains the ID and a person’s static data (such as birthdate and birthplace).
PS_PERS_DATA_EFFDT : Maintains Personal History.
PS_PER_ORG_INST : Stores Employement Instances (ORG_INSTANCE_ERN) of a person.
PS_PER_ORG_ASGN : Person Organizational With Assignment i.e Job Assignments(EMPL_RCD) for each Employement Instance(ORG_INSTANCE_ERN).Each row is uniquely identified by the EMPLID, ORG_INSTANCE_ERN and EMPL_RCD .
PS_PER_POI_TYPE : Person Organizational With out Assignment. Person organizational relationships that do not require an assignment (i.e. JOB data). Each row is uniquely identified by the EMPLID and the POI_TYPE (the person of interest type).
PS_PS_POI_TYPE_TBL : Person Of Interest Type,  which can be configured going through the navigation Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.
PS_PER_POI_SCR_DT : History record of information directly related to one Person of Interest relationship without a job (PS_PER_POI_TYPE).
PS_PER_POI_SCRTY : Row Level Security Contains the field and values of data that can be used to define data Permission Security Access for relationships.
PS_PER_POI_TRANS : This is the generic transaction history record for persons of interest

let us look at the navigation's used in the Person Model

Create POI Type : Set Up HRMS, Foundation Tables, Organization, Person of Interest Type.
Creating a Person : Workforce Administration, Personal Information, Add a Person and Workforce Administration, Personal Information,Biographical, Add a Person
Adding a New Employee Instance : Workforce Administration,Organizational Relationships, New Employement Worker Instance
Adding a POI : Workforce Administration,Organizational Relationships, Add a POI Relationship.
Person Organizational Summary : Workforce Administration, Person Organizational Summary
PERSONAL_DATA Snapshot Settings: Set Up HRMS , System Administration, Database Processes, PERSONAL_DATA Settings
PERS_REFRESH Process : Set Up HRMS, System Administration, Database Processes, Refresh Personal Data.
HR_PERSDATA For Future Dated Rows : Set Up HRMS, System Administration, Database Processes , Update Personal Data - Future.

PERSONAL_DATA Snapshot Reporting Table
The first is for the related display of the NAME field in the PeopleTools User Profile page (USER_MAINT component) The second is for customer written processes and pages.

I hope all this information is useful for understanding what is Person Model.

NA Payroll Table Updates

Paysheet Build / Update via Online or Batch
PS_PAY_PAGE
PS_PAY_LINE
PS_PAY_EARNINGS

PS_PAY_OTH_EARNS
PS_PAY_TAX_OVRD
PS_PAY_GARN_OVRD
PS_PAY_ONE_TIME
(PS_PAY_CTX_OVRD not used for US or PR payrolls)

Pay Calc
PS_PAY_CHECK
PS_PAY_TAX
PS_PAY_DEDUCTION
PS_PAY_SPCL_EARNS
PS_PAY_GARNISH
PS_PAY_MESSAGE

Pay Confirm
PS_PAY_DISTRIBUTN
PS_CHECK_YTD
PS_DEDUCTION_BAL
PS_GARN_BAL
PS_DED_ARREARS
PS_EARNINGS_BAL
PS_TAX_BALANCE