Search Results cs_incidents_ext




Overview
Explore in AI Chat

Overview

CS_INCIDENTS_EXT is a Service (CS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores Service Request Extensible Attribute records. In the EBS data model, Service Requests (incidents) are the central transaction entity managed by the Service Request product family, and CS_INCIDENTS_EXT provides the storage substrate for user-defined descriptive flexfield data attached to those requests. Extensible attributes allow implementors to capture supplementary information beyond the seeded Service Request schema without altering the base tables, making this table an integral part of any Service Request flexfield-enabled deployment.

From a data-modeling perspective, the supplied metadata yields a heuristic Data Vault classification of satellite-leaning. This suggestion reflects the fact that the table carries an EXTENSION_ID surrogate primary key and holds descriptive, attribute-level content keyed back to a parent entity. In Data Vault terms, the table behaves less like a hub (which would carry a business key for the incident) and more like a satellite orbiting the Service Request hub represented by CS_INCIDENTS_ALL_B. Practitioners should treat this classification as a modeling hint rather than an architectural mandate.

Key Information Stored

The documented structure identifies the following critical elements:

  • EXTENSION_ID — the surrogate primary key, enforced by constraint CS_INCIDENTS_EXT_PK. This column uniquely identifies each extensible-attribute extension row and is system-generated.
  • INCIDENT_ID — the foreign key column referencing CS_INCIDENTS_ALL_B. This is the business-key linkage that ties each extension record back to its parent Service Request. Because the metadata does not document any additional unique index, INCIDENT_ID is best understood as the join key rather than a unique business key; depending on the flexfield context configuration, multiple extension rows may associate with a single incident.

Beyond these two documented columns, the remainder of the table follows the standard EBS extensible-attribute column pattern, storing context identifiers and attribute segment values that correspond to the descriptive flexfield definition for Service Requests. Administrators configure which segments are populated, so the populated column set varies by implementation.

Common Use Cases and Queries

The primary use case is reporting and extraction of Service Request flexfield data that is not visible in the base CS_INCIDENTS_ALL_B table. A common query pattern joins the extension table to its parent:

  • Selecting all extensions for a given Service Request: SELECT e.* FROM cs_incidents_ext e WHERE e.incident_id = :incident_id
  • Joining flexfield attributes to base request data: SELECT i.incident_number, e.* FROM cs_incidents_all_b i, cs_incidents_ext e WHERE i.incident_id = e.incident_id
  • Inventory of populated extension records for a reporting period, driven by joins to CS_INCIDENTS_ALL_B on INCIDENT_ID and filtered on creation or update dates in the parent table.

Typical consumers include Service Request detail reports, customer-support dashboards that display configured attributes, and data-migration or integration extracts that must preserve flexfield context. Note that the metadata states this object is "not implemented in this database," meaning the table may be absent or empty in environments where Service Request flexfields have not been configured or where the ETRM extraction was performed against a non-CS installation.

Related Objects

  • CS_INCIDENTS_ALL_B — the base Service Request table and the only documented foreign-key parent. Joined via CS_INCIDENTS_EXT.INCIDENT_ID = CS_INCIDENTS_ALL_B.INCIDENT_ID.
  • CS_INCIDENTS_ALL_TL — translation table for Service Requests, often joined alongside the base table when reporting descriptive request data with extension attributes.
  • FND_DESCR_FLEX_COLUMN_USAGES / FND_DESCR_FLEX_CONTEXTS — flexfield definition tables that describe which segments map into the extension columns.
  • CS_INCIDENT_ATTRIBUTES / dependent CS extension tables — sibling extension structures that store related attribute categories for Service Requests.
  • Service Request public APIs (for example, the CS_ServiceRequest_PUB package and related PL/SQL interfaces) — these populate and maintain extension rows when requests are created or updated through supported interfaces.

All relationships above are anchored on the documented INCIDENT_ID foreign key to CS_INCIDENTS_ALL_B; other associations should be verified against the specific 12.1.1 or 12.2.2 installation, given the limited metadata available.