Results for “cs_sr_action_triggers”

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

Overview

CS_SR_ACTION_TRIGGERS is a Service (CS) module table in Oracle E-Business Suite 12.1.1 and 12.2.2 that stores the event-condition details underpinning Service Request event rules. In the Service Request workflow, actions are fired when a defined event occurs, but only if specific conditions are satisfied. This table captures those conditions and links each one to the event code that raises it. The table is therefore the "when and under what circumstances" layer of the Service Request rule engine, while the sibling table CS_SR_ACTION_DETAILS holds the corresponding "what action to perform" definitions.

From a dimensional modeling perspective, the documented foreign key structure suggests a satellite-leaning classification. The table carries a single-column surrogate primary key, several descriptive attributes, and foreign keys to reference or lookup entities. It is best modeled as a satellite attached to the event-rule hub, with the event and status relationships resolved through separate link structures. This is a heuristic suggestion rather than a mandated design.

Key Information Stored

Each row is uniquely identified by EVENT_CONDITION_ID, the primary key defined by the CS_SR_ACTION_TRIGGERS_PK constraint. A unique index, CS_SR_ACTION_TRIGGERS_U1, covers EVENT_CONDITION_ID together with ZD_EDITION_NAME, which supports edition-based data management in the 12.2.2 schema. The remaining attributes describe the condition itself and its validity window.

• EVENT_CODE — the event that must occur to trigger evaluation, referencing CS_SR_EVENT_CODES_B.
• FROM_TO_STATUS_CODE — indicates whether the condition applies to the source status, the target status, or the transition between them.
• INCIDENT_STATUS_ID — the incident status the condition tests, referencing CS_INCIDENT_STATUSES_B.
• RELATIONSHIP_TYPE_ID — the relationship or link type the condition qualifies, referencing CS_SR_LINK_TYPES_B.
• START_DATE_ACTIVE / END_DATE_ACTIVE — the effective date range during which the condition is active.
• SEEDED_FLAG — distinguishes Oracle-seeded conditions from customer-defined ones.
• APPLICATION_ID — the application that owns the condition record.
• OBJECT_VERSION_NUMBER — optimistic locking column used by the ORM layer.
• CREATION_DATE, CREATED_BY, LAST_UPDATE_DATE, LAST_UPDATED_BY, LAST_UPDATE_LOGIN — standard audit columns.
• ZD_EDITION_NAME — edition identifier used by the 12.2.2 editioning model.

Common Use Cases and Queries

Administrators and developers query this table to understand which conditions govern a given Service Request event, to troubleshoot why a rule did or did not fire, and to audit customer-defined versus seeded conditions. A typical join retrieves the condition alongside the event and status descriptions:

SELECT t.event_condition_id,
       e.event_code,
       e.name            event_name,
       s.status_name,
       t.from_to_status_code,
       t.start_date_active,
       t.end_date_active,
       t.seeded_flag
FROM   cs_sr_action_triggers t,
       cs_sr_event_codes_b    e,
       cs_incident_statuses_b s
WHERE  t.event_code         = e.event_code
AND    t.incident_status_id = s.incident_status_id
AND    SYSDATE BETWEEN t.start_date_active
                   AND NVL(t.end_date_active, SYSDATE + 1);

Reporting commonly focuses on active conditions per event, seeded condition inventories for upgrade impact analysis, and cross-referencing of conditions with their dependent actions in CS_SR_ACTION_DETAILS.

Related Objects

• CS_SR_ACTION_DETAILS — child table; its EVENT_CONDITION_ID column references CS_SR_ACTION_TRIGGERS, holding the action performed when the condition is met.
• CS_SR_EVENT_CODES_B — lookup of event codes via EVENT_CODE.
• CS_INCIDENT_STATUSES_B — incident status lookup via INCIDENT_STATUS_ID.
• CS_SR_LINK_TYPES_B — relationship type lookup via RELATIONSHIP_TYPE_ID.
• CS_SR_ACTION_TRIGGERS_U1 — unique index validating the surrogate key plus edition name.

Together these objects form the Service Request event rule framework, with CS_SR_ACTION_TRIGGERS serving as the condition registry that the rule engine consults before executing any configured action.