Search Results interface_contacts_id




Overview
Explore in AI Chat

Overview

IGS_AD_CONTACTS_INT is an APPS-owned, VALID database view within the IGS – Student System product family of Oracle E-Business Suite 12.1.1 and 12.2.2. The view exposes records from the contact-point interface staging area used by the Student System to load external contact information — email addresses and telephone numbers — into the institutional contact tables. Rather than presenting a normalized business entity, the view surfaces the inbound interface rows together with their processing control columns, including status indicators, error codes, and duplicate-identification fields. As a reporting and integration artifact, IGS_AD_CONTACTS_INT allows technical and functional users to inspect, reconcile, and troubleshoot contact data before or after the interface program consumes it. Because the view carries ORG_ID, REQUEST_ID, PROGRAM_ID, and the standard WHO audit columns, it participates naturally in multi-org and concurrent-request reporting. The presence of the DUP_CONTACT_POINT_ID column is significant: it is the field most commonly targeted when users search for "dup_contact_point_id," since it identifies a previously existing contact point that matches the incoming record, enabling duplicate detection and de-duplication analysis directly through the view.

Underlying Base Objects

The ETRM metadata documents no referenced base objects for this view, and the object is defined with no recorded dependencies. The view text, however, shows a single source: the table IGS_AD_CONTACTS_INT_ALL, aliased as TAB. The view is therefore a thin projection over that interface table, selecting the ROWID as ROW_ID and passing through each interface column without joins, unions, or aggregation. The "_ALL" suffix on the base table indicates a multi-organization structure, so the ORG_ID column is carried through to preserve operating-unit context. No lookup tables, contact master tables, or validation views are joined in the definition, which means the view performs no interpretive decoding — codes such as STATUS, MATCH_IND, and CONTACT_POINT_TYPE are returned as stored. All filtering and enrichment must be supplied by the calling query or concurrent program.

Key Columns

Common Use Cases and Queries

Typical scenarios include auditing failed interface rows, quantifying duplicates before running the contact load, and confirming which records have already been matched or rejected. A straightforward status review is shown below.

  • Identify rows with duplicate contact points: 
    SELECT interface_contacts_id, interface_id, contact_point_type,
       email_address, phone_number, dup_contact_point_id, status
  FROM apps.igs_ad_contacts_int
 WHERE dup_contact_point_id IS NOT NULL
   AND org_id = :p_org_id;
  • List unresolved errors by concurrent request: 
    SELECT request_id, interface_contacts_id, error_code, status
  FROM apps.igs_ad_contacts_int
 WHERE status = 'E'
   AND request_id = :p_request_id;
  • Verify primary contact points loaded for a batch: 
    SELECT interface_id, contact_point_type, email_address, primary_flag
  FROM apps.igs_ad_contacts_int
 WHERE primary_flag = 'Y'
   AND interface_id = :p_interface_id;

Because the view neither validates nor transforms data, all interpretation of codes and duplicate meaning must be applied in the reporting layer.