Search Results cs_incidents_workflow_v




Overview
Explore in AI Chat

Overview

CS_INCIDENTS_WORKFLOW_V is a Service (CS) module view owned by the APPS schema in Oracle E-Business Suite 12.1.1 and 12.2.2. It is documented as being used by the Service Request Workflow, meaning its primary purpose is to supply the Oracle Workflow engine with a denormalized, human-readable projection of service request (incident) data. Rather than requiring workflow notification and message-generation logic to repeatedly join transactional incident tables to lookup, party, and item tables, this view consolidates those attributes into a single queryable object.

The view does not store data of its own; it is a read-only presentation layer over the core incident tables. This makes it equally useful for reporting, custom workflow attribute sourcing, and integration extracts where a flattened view of an incident — including decoded problem, resolution, type, severity, status, and urgency meanings — is required without writing multi-table joins.

Underlying Base Objects

The view is defined over a combination of base views, synonyms, and package references. The driving object is CS_INCIDENTS_ALL_VL, which holds the incident record itself. It is joined to several CS lookup/validation views — CS_INCIDENT_TYPES_VL, CS_INCIDENT_SEVERITIES_VL, CS_INCIDENT_STATUSES_VL, and CS_INCIDENT_URGENCIES_VL — to resolve the corresponding IDs into descriptive names. Customer information is drawn from HZ_PARTIES (via the CUSTOMER_ID), while resource and owner data come from JTF_RS_RESOURCE_EXTNS and CS_SR_OWNERS_V. Product information is sourced from CS_CUSTOMER_PRODUCTS and MTL_SYSTEM_ITEMS_VL.

The problem and resolution codes are decoded through CS_LOOKUPS using lookup types 'REQUEST_PROBLEM_CODE' and 'REQUEST_RESOLUTION_CODE'. The view also references the CS_STD package, specifically CS_STD.GET_ITEM_VALDN_ORGZN_ID, to supply a default validation organization when the item's organization is null, and FND_GLOBAL is referenced for environment/context. The documented base object list also includes the CSICUMPI_PUB package, which is referenced in support of the service request processing logic.

Key Columns

The view exposes the primary incident identifiers — INCIDENT_ID and INCIDENT_NUMBER — along with the SUMMARY and INCIDENT_DATE. Ownership and categorization columns include INCIDENT_OWNER_ID, OWNER, INCIDENT_TYPE, SEVERITY, STATUS_CODE, and URGENCY.

Critically for the search term problem_code_meaning, the view exposes both the raw PROBLEM_CODE and the decoded PROBLEM_CODE_MEANING, with the meaning resolved from CS_LOOKUPS.MEANING for the 'REQUEST_PROBLEM_CODE' lookup type. A parallel PROBLEM_CODE_DESCRIPTION column is also provided. The same decode pattern applies to resolution codes, yielding RESOLUTION_CODE, RESOLUTION_CODE_MEANING, and RESOLUTION_CODE_DESCRIPTION. Additional columns include INVENTORY_ITEM_ID, PRODUCT_DESCRIPTION, CUSTOMER_PRODUCT_ID, CUSTOMER_NAME, and EXPECTED_RESOLUTION_DATE.

Common Use Cases and Queries

Typical uses include workflow notification content population, operational dashboards showing incidents with decoded problem/resolution meanings, and data extracts feeding reporting tools such as Oracle BI or custom concurrent programs. A representative query to retrieve the decoded problem code meaning for open incidents follows:

  • SELECT incident_number, summary, problem_code, problem_code_meaning, resolution_code_meaning, status_code FROM cs_incidents_workflow_v WHERE problem_code IS NOT NULL;
  • SELECT incident_type, severity, urgency, status_code, COUNT(*) FROM cs_incidents_workflow_v GROUP BY incident_type, severity, urgency, status_code;

Because the view already decodes lookups, queries are simpler and less error-prone than joining CS_INCIDENTS_ALL_VL to CS_LOOKUPS directly. Note that several joins use outer joins (+), so incidents lacking a severity, urgency, owner, or customer will still appear with nulls in the corresponding descriptive columns.