Search Results cs_incident_severities_b




Overview
Explore in AI Chat

Overview

The table CS_INCIDENT_SEVERITIES_B is a core reference data object within the Oracle E-Business Suite Service (CS) module. It serves as the master repository for defining and managing the severity levels that can be assigned to Service Requests (SRs) or Incidents. Severities are critical for prioritizing support work, managing service level agreements (SLAs), and categorizing the business impact of reported issues. This table stores the non-translated, base information for each severity definition, which is then typically referenced by translated descriptive data in a related TL (translated) table. Its role is foundational to the incident management and service delivery processes in Oracle EBS.

Key Information Stored

The table's structure, as indicated by its primary and unique keys, centers on two critical identifiers. The primary key is the INCIDENT_SEVERITY_ID, a system-generated unique sequence number that serves as the main internal identifier for a severity record. Crucially, the metadata reveals a unique key constraint on the INCIDENT_SUBTYPE column. This design implies that within the context of a specific incident subtype (a classification of service requests), severity definitions must be unique. Other important columns, inferred from standard EBS practice and the foreign key reference, include a DEFECT_SEVERITY_ID, which likely links to a related defect severity definition, and columns for name, description, active status, and creation/update metadata.

Common Use Cases and Queries

This table is primarily queried for validation, reporting, and data population. A common use case is validating the severity assigned to a service request during data entry or an API call. For reporting, analysts join this table to incident transaction tables to analyze trends by severity level. Given the user's search for "incident_subtype," a typical query pattern would involve finding all valid severities for a specific subtype, which is essential for building dynamic LOVs (Lists of Values) in forms or self-service interfaces.

  • Sample Query: Retrieve active severities for a specific incident subtype.
    SELECT incident_severity_id, name
    FROM cs_incident_severities_b
    WHERE incident_subtype = '<SUBTYPE_CODE>'
    AND SYSDATE BETWEEN start_date_active AND NVL(end_date_active, SYSDATE);
  • Sample Query: Join to transaction table for reporting.
    SELECT i.incident_number, sev.name severity, i.creation_date
    FROM cs_incidents_all_b i,
    cs_incident_severities_b sev
    WHERE i.incident_severity_id = sev.incident_severity_id;

Related Objects

The primary relationship for this table is with the transaction table CS_INCIDENTS_ALL_B, which holds the individual service request records. The foreign key (CS_INCIDENTS_ALL_B.INCIDENT_SEVERITY_ID) references this table to enforce data integrity for the severity assigned to each incident. The table also has a self-referencing foreign key on DEFECT_SEVERITY_ID, indicating a potential hierarchical or mapping relationship within the same table. For multilingual implementations, a related table such as CS_INCIDENT_SEVERITIES_TL would store the translated names and descriptions. This reference data is also integral to the underlying logic of the Service Request APIs and the Service Contracts module for SLA management.