Results for “contact_role_code”

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

Overview

AST_SALES_LEAD_CONTACTS_V is a TeleSales (AST) reporting view owned by the APPS schema and validated in Oracle EBS 12.1.1 and 12.2.2. It presents the contact-level detail for sales leads: each row links a sales lead to a contact party, that party's role on the lead, associated phone and e-mail contact points, organizational job information, and the underlying party relationship. The view is a denormalized, read-only projection intended for inquiry, concurrent-program extracts, and integration interfaces that require lead-contact information without joining the base tables directly.

The object is significant for the search term lead_contact_role because the role of each contact is exposed through CONTACT_ROLE_CODE and its decoded, user-facing value MEANING (aliased from AS_LOOKUPS as ROLE_LKUP). Consumers can therefore report or filter on lead contact roles without decoding lookups themselves.

Underlying Base Objects

The view is defined over seven documented base objects. The driving table is AS_SALES_LEAD_CONTACTS (referenced as the synonym LEAD_CONT), which supplies the lead-contact intersection records. Supporting objects are:

• HZ_PARTIES (PARTY_CONT) joined on PARTY_ID = REL.SUBJECT_ID, providing the contact's first and last name.
• HZ_RELATIONSHIPS (REL), joined on LEAD_CONT.CONTACT_PARTY_ID = REL.PARTY_ID and LEAD_CONT.CUSTOMER_ID = REL.OBJECT_ID, supplying relationship identifiers and subject/object party keys.
• HZ_ORG_CONTACTS (ORG_CONT), supplying job title and job title code for organizational contacts.
• HZ_CONTACT_POINTS joined twice — PHONE on LEAD_CONT.PHONE_ID = PHONE.CONTACT_POINT_ID(+) (outer join) for telephone data, and PHONE1 for the e-mail address.
• AS_LOOKUPS (ROLE_LKUP) for the contact role meaning.
• AR_LOOKUPS (AR_LKUP1, AR_LKUP2, AR_LKUP3) for additional decoded meanings, including relationship and job title code descriptions.

The outer join on the phone contact point means lead contacts without a phone record still appear, with phone columns null.

Key Columns

• LEAD_CONTACT_ID, SALES_LEAD_ID, CONTACT_ID, CONTACT_PARTY_ID — primary identifiers linking the lead-contact record to its lead, contact, and party.
• CONTACT_ROLE_CODE and MEANING — the lead contact role and its decoded display value; central to role-based reporting.
• PRIMARY_CONTACT_FLAG, ENABLED_FLAG, RANK — indicate the primary contact, record status, and ordering/priority of the contact.
• CUSTOMER_ID, ADDRESS_ID, PHONE_ID — customer, address, and phone references.
• PERSON_FIRST_NAME, PERSON_LAST_NAME, JOB_TITLE, JOB_TITLE_CODE — contact identity and organizational role.
• RELATIONSHIP_ID, RELATIONSHIP_CODE, SUBJECT_ID, OBJECT_ID — party relationship context.
• EMAIL_ADDRESS, RAW_PHONE_NUMBER, and the concatenated phone expression (PHONE_COUNTRY_CODE, PHONE_AREA_CODE, PHONE_NUMBER, PHONE_EXTENSION), PHONE_LINE_TYPE — communication details.
• Standard WHO/audit columns: CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN, and ATTRIBUTE1–ATTRIBUTE15 with ATTRIBUTE_CATEGORY for descriptive flexfield data.

Common Use Cases and Queries

The view supports lead-contact reporting, role analysis, and data migration extracts. Typical queries include:

• Listing all contacts for a given sales lead with their roles:

SELECT sales_lead_id, contact_party_id, person_first_name,
       person_last_name, contact_role_code, meaning
FROM   apps.ast_sales_lead_contacts_v
WHERE  sales_lead_id = :p_lead_id
AND    enabled_flag = 'Y';

• Filtering by a specific lead contact role:

SELECT sales_lead_id, person_last_name, email_address, phone_line_type
FROM   apps.ast_sales_lead_contacts_v
WHERE  contact_role_code = :p_role_code;

• Identifying the primary contact for each lead:

SELECT sales_lead_id, person_first_name, person_last_name
FROM   apps.ast_sales_lead_contacts_v
WHERE  primary_contact_flag = 'Y'
AND    enabled_flag = 'Y';

Because the view joins multiple HZ and lookup tables, queries should be constrained by lead, customer, or role to limit result sets. No DML is permitted against the view.