Results for “interface_appint_id”

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

Overview

The IGS_AD_APPINT_INT table is a core interface (staging) table within the IGS – Student System product of Oracle E-Business Suite. It resides in the IGS schema and holds information about a person's applicant intent details prior to validation and migration into the base admissions tables. In release 12.1.1 the documented physical schema contains 40 columns, and its status is VALID across both 12.1.1 and 12.2.2. The table acts as a persistent landing area for inbound admissions data, capturing applicant intent records that are later processed by concurrent programs.

From a data modeling perspective, the metadata's heuristic Data Vault classification labels this object as standalone, meaning it is not heavily normalized into hub/link/satellite constructs. Because it carries a surrogate primary key, a natural business key candidate, and descriptive attributes, it could reasonably be modeled as a satellite attached to the applicant/admission application hub, with an optional link to the person entity. This is offered as a modeling suggestion rather than a documented classification.

Key Information Stored

The following columns are the most significant for integration, reporting, and troubleshooting:

• INTERFACE_APPINT_ID – Surrogate primary key (IGS_AD_APPINT_INT_PK) and the sole candidate for the ALL_U1 unique index, uniquely identifying each staged intent record.
• INTERFACE_APPL_ID – Foreign key to IGS_AD_APL_INT, linking the intent to its parent application record.
• INTENT_TYPE_ID – Identifies the type of applicant intent being recorded.
• PERSON_ID – The person associated with the intent, tying the record to the person registry.
• ADMISSION_APPL_NUMBER – The admission application number used to reconcile with the admissions module.
• ADMISSION_APPLICATION_TYPE – Classifies the admission application.
• STATUS – Processing state of the staged record (e.g., ready, processed, error).
• ERROR_CODE and ERROR_TEXT – Diagnostic fields populated when validation or migration fails.
• INTERFACE_RUN_ID – Groups records belonging to a single interface run.
• REQUEST_ID, PROGRAM_ID, PROGRAM_APPLICATION_ID, PROGRAM_UPDATE_DATE – Concurrent program and request audit columns.
• CREATED_BY, CREATION_DATE, LAST_UPDATED_BY, LAST_UPDATE_DATE, LAST_UPDATE_LOGIN – Standard who-columns.
• ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE20 – Descriptive flexfield (DFF) columns for extensible intent data.

Common Use Cases and Queries

Typical usage centers on loading, validating, and reporting on staged applicant intent data. An integration analyst might query pending records before running the validation process:

• Error triage: SELECT INTERFACE_APPINT_ID, ERROR_CODE, ERROR_TEXT FROM IGS_AD_APPINT_INT WHERE STATUS = 'ERROR';
• Run monitoring: SELECT INTERFACE_RUN_ID, COUNT(*) FROM IGS_AD_APPINT_INT GROUP BY INTERFACE_RUN_ID;
• Applicant lookup: joining on PERSON_ID to reconcile intents with a specific person.
• Reporting on intent types and admission application types for admissions funnel analysis.

Related Objects

The most significant related object is the parent interface table, joined via the documented foreign key:

• IGS_AD_APL_INT – referenced by IGS_AD_APPINT_INT.INTERFACE_APPL_ID; the primary parent table holding staged application headers.
• IGS_AD_APPINT – the base admissions applicant intent table that receives validated records.
• IGS_AD_APL – base admission application table linked through the application number.
• HZ_PARTIES / PERSON registry – via PERSON_ID for the applicant identity.
• IGS concurrent programs and APIs that read from and write to these interface tables during the admissions import cycle.