Results for “per_person_list”

AI-generated from documented ETRM metadata — verify critical details on the linked pages.

Overview

PER_PERSON_LIST is a Human Resources (PER) module table in the HR schema that materializes the set of people a secure user is permitted to access. It functions as a pre-computed access control list: rather than evaluating security profile logic at query time, Oracle EBS stores the resulting person-by-profile assignments here. Each row associates a security profile with a specific person and records the user to whom access was granted. The table is classified as VALID in both Oracle EBS 12.1.1 and 12.2.2 and is populated through the security profile generation process rather than through direct user data entry.

Under a heuristic Data Vault classification, the foreign key structure places this object as satellite-leaning. It does not own the person or profile entities themselves; instead it carries dependent attributes describing the grant of access, including which user received it and the concurrent request context in which it was created. This makes it a natural candidate for a satellite attached to a person-to-profile link, rather than a standalone hub or pure junction table.

Key Information Stored

The table contains seven documented columns. The most significant are:

• SECURITY_PROFILE_ID — Identifies the security profile that governs the access rule. This is the foreign key pointing to PER_SECURITY_PROFILES and forms the leading column of both the primary key and the business-key unique index.
• PERSON_ID — Identifies the person record whose accessibility is being granted. Together with SECURITY_PROFILE_ID, it constitutes the primary key PER_PERSON_LIST_PK.
• GRANTED_USER_ID — Identifies the application user who received access to the person. This column completes the unique index PER_PERSON_LIST_UK1.
• REQUEST_ID — The concurrent request that created or refreshed the row, used for batch auditing and troubleshooting of security profile runs.
• PROGRAM_APPLICATION_ID, PROGRAM_ID, and PROGRAM_UPDATE_DATE — Concurrent program identifiers and the timestamp of the last programmatic update, providing lineage for the generating process.

The surrogate primary key is PER_PERSON_LIST_PK, composed of SECURITY_PROFILE_ID and PERSON_ID. A second unique constraint, PER_PERSON_LIST_UK1, extends this with GRANTED_USER_ID, distinguishing grants issued to different users under the same profile. The distinction matters because the primary key enforces uniqueness per profile-person pair, while the business key reflects the finer grain of user-level grants.

Common Use Cases and Queries

The principal use case is resolving which persons a given user may see, typically to drive list-of-values filters, self-service person searches, or custom reports that must respect HR security. A representative query joins the table to security profiles and person records:

SELECT ppl.person_id, ppl.security_profile_id, ppl.granted_user_id
FROM   per_person_list ppl, per_security_profiles psp
WHERE  ppl.security_profile_id = psp.security_profile_id
AND    ppl.granted_user_id = :user_id;

Administrators and support teams also reverse the query to determine why a user can or cannot access a particular person, examining whether the security profile generation has run recently by inspecting PROGRAM_UPDATE_DATE and REQUEST_ID. Reporting scenarios include auditing of access breadth per profile, identifying stale grants after employee transfers, and validating row counts after a security refresh. Because the data is derived, any diagnostic investigation should trace back to the generating concurrent request rather than treating the rows as authoritative.

Related Objects

• PER_SECURITY_PROFILES — Referenced via PER_PERSON_LIST.SECURITY_PROFILE_ID; defines the profile rules that produce these rows.
• PER_ALL_PEOPLE_F — Joined on PERSON_ID to obtain person names, employee numbers, and current assignments.
• PER_SECURITY_PROFILE_ORGS — Organization-level counterpart that scopes profiles to organizations.
• PER_SECURITY_PROFILE_ASSIGNMENTS — Assignment-level security rows, applying security at the assignment granularity.
• FND_USER — Joined on GRANTED_USER_ID to resolve the user name behind the grant.
• FND_CONCURRENT_REQUESTS — Joined on REQUEST_ID to identify the security refresh run.

Collectively these objects form the HR security access model in which PER_PERSON_LIST supplies the resolved person-level grants.