Search Results per_position_list




Overview
Explore in AI Chat

Overview

PER_POSITION_LIST is an Oracle E-Business Suite table owned by the HR schema and delivered under the PER (Human Resources) product family. Its documented purpose is to hold the list of positions that a secure user is permitted to access. In practice, the table functions as a materialized security access list: rather than evaluating position security dynamically at query time, Oracle HRMS resolves each user's position-level security profile into discrete rows within PER_POSITION_LIST, and downstream forms, concurrent programs, and reporting queries consult this table to determine which positions a given user may see or transact against.

The table is present and valid in both EBS 12.1.1 and 12.2.2. Its documented physical schema comprises seven columns in the HR schema. Under a heuristic Data Vault classification derived from its foreign key structure, PER_POSITION_LIST is best modeled as a link table. It resolves a many-to-many association between a security profile and the positions granted under it (and, in the extended unique key, the user to whom that grant applies), which is the classic role of a link entity rather than a hub or satellite.

Key Information Stored

The table's principal business content is captured in a small set of columns:

The documented surrogate primary key, PER_POSITION_LIST_PK, is defined on (SECURITY_PROFILE_ID, POSITION_ID). The documented business-key candidate, PER_POSITION_LIST_UK1, is the wider composite (SECURITY_PROFILE_ID, POSITION_ID, USER_ID), which uniquely identifies a user's access to a given position under a given profile.

Common Use Cases and Queries

The table is most commonly queried to audit or diagnose position-level security, and to validate why a user can or cannot see a particular position in an HRMS form or report.

A typical access check joins the list back to the position definition:

  • SELECT ppl.position_id, pap.name FROM per_position_list ppl, per_all_positions pap WHERE ppl.position_id = pap.position_id AND ppl.user_id = :user_id;
  • Comparing a user's resolved list against the profile definition to detect missing or stale rows after a security refresh.
  • Reporting the total number of positions exposed per security profile for segregation-of-duties reviews.
  • Reconciling rows by PROGRAM_UPDATE_DATE to confirm when a security refresh concurrent program last ran for a population of users.

Because effective access is stored per user, the USER_ID predicate should generally be supplied to keep queries selective and to avoid returning the full cross-product of profiles and positions.

Related Objects

The most significant related objects, based on the documented foreign keys and key structure, are:

  • PER_SECURITY_PROFILES — Parent of SECURITY_PROFILE_ID; defines the security profile that grants the positions.
  • PER_ALL_POSITIONS — Parent of POSITION_ID; supplies the position definition and descriptive attributes.
  • PER_POSITION_LIST_PK / PER_POSITION_LIST_UK1 — The primary and unique indexes enforcing row identity and per-user uniqueness.
  • FND_USER — References USER_ID for the effective user identity (logical, not a documented FK).
  • FND_CONCURRENT_REQUESTS / FND_CONCURRENT_PROGRAMS — Correlate the REQUEST_ID, PROGRAM_ID, and PROGRAM_APPLICATION_ID audit columns to the refresh run.