Search Results irc_pending_data




Overview
Explore in AI Chat

Overview

IRC_PENDING_DATA is a table owned by the HR schema within the PER (Human Resources) product family of Oracle E-Business Suite. Its documented purpose is to store user applications created on a High Availability instance. In practical terms, the table acts as a staging and intake repository for iRecruitment self-service applications submitted by external candidates and visitors, capturing the submission payload before it is validated and transferred into the core applicant and vacancy structures. In Oracle EBS 12.1.1 and 12.2.2, this object is the persistence layer that allows recruitment activity to continue on a secondary or read-replica node without immediately writing to the primary transactional tables, with the data later reconciled into the mainstream HR tables.

From a heuristic Data Vault modeling perspective, the mined FK structure classifies this table as standalone. Because it is not modeled as a dependent child of a broader hub-and-link construct, it is best treated as an independent staging or intake entity rather than a true hub, link, or satellite. The VACANCY_ID and POSTING_CONTENT_ID foreign keys, however, show that submissions are still anchored to a vacancy and a posting content record, giving the table context within the recruitment flow.

Key Information Stored

The surrogate primary key is PENDING_DATA_ID, defined through the IRC_PENDING_DATA_PK constraint. A second documented unique index, IRC_PENDING_DATA_U1, covers EMAIL_ADDRESS and VACANCY_ID, which serves as the principal business-key candidate: a given email address is expected to appear only once per vacancy.

The most significant columns include:

  • PENDING_DATA_ID — surrogate primary key identifying each pending submission.
  • EMAIL_ADDRESS and VACANCY_ID — the documented unique business key, linking a candidate email to a specific vacancy.
  • FIRST_NAME, LAST_NAME, SEX, DATE_OF_BIRTH — core applicant biographical data.
  • USER_PASSWORD and USER_GUID — credentials and identity tokens for the candidate session created on the High Availability instance.
  • RESUME, RESUME_FILE_NAME, RESUME_DESCRIPTION, RESUME_MIME_TYPE — the attached resume payload and its descriptive metadata.
  • SOURCE_TYPE and JOB_POST_SOURCE_NAME — the channel through which the application originated.
  • POSTING_CONTENT_ID and PERSON_ID — references to the posting content record and to an existing person where one already exists.
  • PROCESSED — the flag indicating whether the pending record has been reconciled into the core applicant tables.
  • ERROR_MESSAGE — the validation or transfer failure detail when the record cannot be processed.
  • SECURITY_GROUP_KEY and ALLOW_ACCESS — row-level security and access control for the submission.
  • PER_INFORMATION1 through PER_INFORMATION30 — the descriptive flexfield segments that capture client-specific application attributes.
  • LAST_UPDATE_DATE and CREATION_DATE — standard audit columns.

Common Use Cases and Queries

The primary operational use case is monitoring the reconciliation backlog of High Availability applications. Administrators query unprocessed rows to confirm that submissions transfer cleanly into the core recruitment tables:

  • SELECT pending_data_id, email_address, vacancy_id, creation_date FROM irc_pending_data WHERE processed = 'N' ORDER BY creation_date;
  • SELECT email_address, vacancy_id, error_message FROM irc_pending_data WHERE error_message IS NOT NULL;
  • SELECT COUNT(*) FROM irc_pending_data WHERE vacancy_id = :vacancy_id GROUP BY vacancy_id;

Reporting use cases include measuring application volume per vacancy, analyzing source channel effectiveness through SOURCE_TYPE and JOB_POST_SOURCE_NAME, and auditing duplicate or suspect submissions by validating against the EMAIL_ADDRESS and VACANCY_ID business key. Candidates with stored resumes are frequently joined to IRC_POSTING_CONTENTS to reconstruct the posting context of an application.

Related Objects

  • PER_ALL_VACANCIES — referenced through IRC_PENDING_DATA.VACANCY_ID; the vacancy the submission is directed against.
  • IRC_POSTING_CONTENTS — referenced through IRC_PENDING_DATA.POSTING_CONTENT_ID; the specific posting content displayed to the candidate.
  • PER_ALL_PEOPLE_F — the destination structure where PERSON_ID is resolved and applicant records are created.
  • IRC_APPLICANTS — the core applicant table populated once PROCESSED is set after successful transfer.
  • HR_APPLICANT_SECURITY / security group constructs — used with SECURITY_GROUP_KEY to enforce row-level access on submissions.
  • PER_PERSON_TYPES and related person setup tables — consumed during conversion of pending records into full applicant records.