Results for “nominated_by_person_id”

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

Overview

PA_CANDIDATES is a transaction table within the Oracle Projects (PA) module of Oracle E-Business Suite 12.1.1 and 12.2.2. It stores the pool of resources that have been nominated as candidates against a project requirement. Each row represents a single candidate nomination, linking a resource to a specific assignment and capturing the nomination context, ranking, status, and reviewer activity that flows through the resource-search and staffing process.

The table is owned by the PA schema and is flagged VALID in the documented ETRM 12.2.2 physical schema. Its primary key, PA_CANDIDATES_PK, is defined on the CANDIDATE_ID column, which users searching for "pa_candidates_pk" most commonly encounter when joining this table to its dependent child tables or writing constraint-aware queries.

From a Data Vault modeling perspective, the mined relationship structure classifies PA_CANDIDATES as satellite-leaning. It behaves like a satellite attached to the assignment and resource hubs, recording descriptive nomination attributes keyed by a surrogate identifier rather than acting as a pure hub or a many-to-many link. This classification is a heuristic suggestion based on foreign-key topology, not a documented Oracle construct.

Key Information Stored

The documented physical schema contains 30 columns. The most significant are:

• CANDIDATE_ID — the surrogate primary key (PA_CANDIDATES_PK) and the unique business-key column (PA_CANDIDATES_U1). All child tables reference this value.
• ASSIGNMENT_ID — foreign key to PA_PROJECT_ASSIGNMENTS, identifying the assignment the candidate is being considered for.
• RESOURCE_ID — foreign key to PA_RESOURCES, identifying the nominated resource.
• STATUS_CODE — the current nomination state (for example nominated, reviewed, or rejected).
• NOMINATED_BY_PERSON_ID and NOMINATION_DATE — who raised the nomination and when.
• NOMINATION_COMMENTS — free-text justification supplied at nomination time.
• CANDIDATE_RANKING — relative standing of the candidate against competing nominations.
• RECORD_VERSION_NUMBER — optimistic locking counter for concurrent updates.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1 through ATTRIBUTE15 — the standard descriptive flexfield (DFF) segment set.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — the standard WHO audit columns.

The distinction between the surrogate key and the business key matters for integration: CANDIDATE_ID is the only documented unique index, so it serves as both the technical primary key and the de facto business identifier used by downstream tables.

Common Use Cases and Queries

Typical reporting scenarios include identifying open candidate nominations by status, ranking candidates for a single assignment, and auditing reviewer throughput. A standard join pattern resolves candidates to their underlying assignment and resource:

• SELECT c.candidate_id, c.status_code, c.candidate_ranking, r.name FROM pa_candidates c, pa_resources r WHERE c.resource_id = r.resource_id AND c.assignment_id = :assignment_id
• SELECT c.candidate_id, c.nomination_date, c.nominated_by_person_id FROM pa_candidates c WHERE c.status_code = 'NOMINATED' ORDER BY c.nomination_date
• Count candidates per assignment for workload analysis: SELECT assignment_id, COUNT(*) FROM pa_candidates GROUP BY assignment_id

Because PA_CANDIDATES is satellite-leaning, extract/ETL routines commonly land it as a satellite table keyed on CANDIDATE_ID, with ASSIGNMENT_ID and RESOURCE_ID retained as hub references. Queries joining on PA_CANDIDATES_PK columns should always use CANDIDATE_ID, since this is the only unique-indexed column documented.

Related Objects

PA_CANDIDATES sits in the center of a small cluster of staffing objects. The documented foreign keys and reverse references are:

• PA_PROJECT_ASSIGNMENTS — referenced via PA_CANDIDATES.ASSIGNMENT_ID; defines the assignment a candidate is nominated for.
• PA_RESOURCES — referenced via PA_CANDIDATES.RESOURCE_ID; supplies the nominated resource identity.
• PA_CANDIDATE_REVIEWS — child table referencing PA_CANDIDATES; carries reviewer scores, comments, and review outcomes. Note the documentation lists both CANDIDATE_REVIEW_ID and CANDIDATE_ID as reference paths, reflecting the review-to-candidate relationship.
• PA_CANDIDATES_AR — audit/shadow table (AR suffix) mirroring PA_CANDIDATES, populated on update or delete for audit trail purposes and joined on CANDIDATE_ID.
• PA_CANDIDATES_REV_AR — the corresponding revision audit table, also joined on CANDIDATE_ID.

Together these objects support the full requirement-to-candidate-to-review lifecycle. Any query or interface touching PA_CANDIDATES should account for the audit tables whenever historical or audited candidate data is required, and should respect the CANDIDATE_ID primary key as the single reliable join anchor across the cluster.