Search Results cs_incident_cycle_steps




Overview
Explore in AI Chat

Overview

The CS_INCIDENT_CYCLE_STEPS table is a core data object within the Oracle E-Business Suite (EBS) Service (CS) module, specifically in versions 12.1.1 and 12.2.2. It functions as a configuration and control table that defines the permissible workflow for service requests, known as incidents. Its primary role is to store the valid sequence of status transitions, or "cycle steps," that an incident can follow based on its type and current status. This table is essential for enforcing business rules and maintaining data integrity as incidents progress through their lifecycle from creation to resolution, ensuring that status changes are logical and controlled.

Key Information Stored

The table's structure centers on defining relationships between incident types, statuses, and subsequent allowable steps. While the full column list is not detailed in the provided metadata, the foreign key relationships explicitly identify the critical columns. The primary key, INCIDENT_CYCLE_STEPS_ID, uniquely identifies each valid status transition rule. The two key foreign key columns are INCIDENT_TYPE_ID, which links to CS_INCIDENT_TYPES_B to specify the service request category, and INCIDENT_STATUS_ID, which links to CS_INCIDENT_STATUSES_B to specify the current status. The table likely contains additional columns to define the next permissible status or step in the cycle, effectively mapping a "from" status to one or more "to" statuses for a given incident type.

Common Use Cases and Queries

This table is primarily accessed by the application's underlying logic to validate user actions. When a user attempts to update an incident's status, the application queries this table to verify if the transition is allowed. Common reporting and query use cases involve analyzing or documenting configured workflow paths. A typical SQL pattern retrieves the valid next steps for a specific incident type and status:

  • SELECT * FROM cs_incident_cycle_steps WHERE incident_type_id = &type_id AND incident_status_id = ¤t_status_id;

Another common query joins with the related descriptive tables to produce a readable workflow map:

  • SELECT it.name type_name, cs_from.name from_status, cs_to.name to_status FROM cs_incident_cycle_steps cics JOIN cs_incident_types_tl it ON cics.incident_type_id = it.incident_type_id JOIN cs_incident_statuses_tl cs_from ON cics.incident_status_id = cs_from.incident_status_id JOIN cs_incident_statuses_tl cs_to ON cics.next_status_id = cs_to.incident_status_id WHERE it.language = USERENV('LANG');

Related Objects

As indicated by its foreign keys, CS_INCIDENT_CYCLE_STEPS has direct dependencies on two key base tables. It references CS_INCIDENT_TYPES_B to categorize the service request and CS_INCIDENT_STATUSES_B to define the specific statuses involved in the transition. It is a parent table to the transactional history, likely referenced by the main incidents table (CS_INCIDENTS_ALL_B) or a related audit table that records status change history. This configuration table is central to the status engine within the Service module, and any customizations to incident workflows would involve modifications or extensions to the rules stored here.