Results for “cs_incident_cycle_steps”

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

Overview

The CS_INCIDENT_CYCLE_STEPS table resides in the CS schema of Oracle E-Business Suite and forms part of the Service (TeleService/Depot Repair) module. It stores the definition of the incident lifecycle: the ordered set of status steps through which a service incident progresses, and the rules governing transitions between those steps. Each row associates a particular incident type with a particular incident status and establishes its position (level) within the cycle, the next step permitted, and behavioral flags such as whether the step validates the incident or closes it.

Functionally, the table acts as the configuration backbone behind the incident status workflow. The Service module uses it to control which statuses are available for a given incident type, how an incident advances from one status to the next, and which transitions are terminal. Administrators maintain the data through the Service setup and status-transition user interfaces, and the runtime application reads it to render valid status choices and to enforce transition rules.

Under the heuristic Data Vault classification mined from the foreign-key structure, this object is best modeled as a link. It carries no descriptive master attributes of its own overarching entity; instead, it resolves the many-to-many relationship between incident types and incident statuses, adding the step-level sequencing and transition semantics that qualify that association. The classification is a modeling suggestion, not a physical constraint imposed by EBS.

Key Information Stored

The documented physical schema exposes 34 columns. The most operationally significant are listed below.

• INCIDENT_CYCLE_STEPS_ID — the surrogate primary key, enforced by CS_INCIDENT_CYCLE_STEPS_PK and also by the unique index CS_INCIDENT_CYCLE_STEPS_U1. Serves as the internal row identifier.
• INCIDENT_TYPE_ID — foreign key to CS_INCIDENT_TYPES_B; identifies the incident type to which the cycle belongs.
• INCIDENT_STATUS_ID — foreign key to CS_INCIDENT_STATUSES_B; identifies the status that this step represents.
• STEP_LEVEL — the ordinal position of the status within the cycle for the given incident type.
• NEXT_INCIDENT_STEP_LEVEL — the level to which the incident advances from this step, defining the transition path.
• DESCRIPTION — a descriptive label for the step.
• START_DATE_ACTIVE and END_DATE_ACTIVE — date-effectivity controls bounding when the step is valid.
• VALIDATE_FLAG — indicates whether the step triggers validation logic during progression.
• CLOSE_FLAG — indicates whether the step represents a terminal, closing status.
• SECURITY_GROUP_ID — foreign key to FND_SECURITY_GROUPS, supporting multi-organization access control.
• UPGRADED_STATUS_FLAG — records whether the step definition was affected by an upgrade conversion.
• OBJECT_VERSION_NUMBER, LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, and LAST_UPDATE_LOGIN — standard concurrency-control and audit columns maintained by the framework.

The business-key candidate is the unique index CS_INCIDENT_CYCLE_STEPS_U2 on (INCIDENT_TYPE_ID, INCIDENT_STATUS_ID), which guarantees that a given status appears only once per incident type. The columns ATTRIBUTE1 through ATTRIBUTE15 and CONTEXT provide the standard descriptive-flexfield extension area.

Common Use Cases and Queries

The most frequent usage is retrieving the valid, ordered statuses for an incident type, either for setup validation or for reporting on cycle configuration.

• List the active cycle steps for an incident type: join CS_INCIDENT_TYPES_B on INCIDENT_TYPE_ID and CS_INCIDENT_STATUSES_B on INCIDENT_STATUS_ID, filtering on START_DATE_ACTIVE and END_DATE_ACTIVE to restrict to currently effective rows.
• Build the transition map: select INCIDENT_TYPE_ID, STEP_LEVEL, INCIDENT_STATUS_ID, and NEXT_INCIDENT_STEP_LEVEL, ordering by STEP_LEVEL, to visualize the workflow path and identify closing steps via CLOSE_FLAG.
• Data-repair and audit queries: detect orphaned steps whose INCIDENT_STATUS_ID no longer resolves in CS_INCIDENT_STATUSES_B, or duplicate business keys despite CS_INCIDENT_CYCLE_STEPS_U2.
• Impact analysis before changing a status: count rows by INCIDENT_STATUS_ID to determine how many incident types depend on a given status before it is retired.
• Reporting: join to descriptions from CS_INCIDENT_TYPES_B and CS_INCIDENT_STATUSES_B to produce readable status definitions for support dashboards and documentation.

Queries should generally exclude rows with expired END_DATE_ACTIVE values and honor SECURITY_GROUP_ID when running in a multi-organization context.

Related Objects

• CS_INCIDENT_TYPES_B — joined on INCIDENT_TYPE_ID; the master definition of the incident type whose cycle is configured here.
• CS_INCIDENT_STATUSES_B — joined on INCIDENT_STATUS_ID; supplies status names and codes referenced by each step.
• FND_SECURITY_GROUPS — joined on SECURITY_GROUP_ID; governs which organizations may access each step record.
• CS_INCIDENTS_ALL — the transactional incident fact table, whose status column reflects the status reached through these configured steps; used in reporting joins.
• CS_INCIDENT_CYCLE_STEPS_PK and CS_INCIDENT_CYCLE_STEPS_U1/U2 — the constraints and unique indexes that enforce row identity and the business key.
• TeleService setup APIs and concurrent programs — the Service module setup interfaces that insert, update, and validate rows in this table.

Together these objects position CS_INCIDENT_CYCLE_STEPS as the configuration link between incident classification and incident status, driving the lifecycle behavior of the Service module in both Oracle EBS 12.1.1 and 12.2.2.