Results for “eam_safety_workflows”

34 results




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

Overview

EAM.EAM_SAFETY_WORKFLOWS is a table within the Oracle Enterprise Asset Management (EAM) module of Oracle E-Business Suite, valid in both release 12.1.1 and 12.2.2. Its documented purpose is to store workflow item type and workflow key values that correspond to safety objects in EAM. In practical terms, the table acts as a cross-reference bridge between EAM safety records (such as safety plans, permits, or incident-related entities) and the Oracle Workflow engine, allowing the EAM application to locate and manage the specific workflow instance associated with a given safety transaction.

The ETRM metadata carries a heuristic Data Vault classification of standalone, meaning the mined foreign-key structure does not reveal inbound or outbound FK dependencies. Under a Data Vault modeling lens, this would suggest treating the object as neither a conventional hub nor link, but rather as an isolated structure — effectively a satellite-like store keyed on its own surrogate identifier — with no dependent relationships to normalize around. This classification should be read as a modeling suggestion rather than an authoritative constraint, since it is derived from FK mining rather than from documented referential integrity rules.

Key Information Stored

The physical schema documents eight columns for release 12.2.2. The most significant are:

  • TRANSACTION_ID — the surrogate primary key, enforced through EAM_SAFETY_WORKFLOWS_PK. This is the unique system-generated identifier for each row and is the only column named in the documented primary-key definition.
  • OBJECT_ID — identifies the safety object to which the workflow binding applies. This is the principal business-key candidate linking a workflow record back to the safety entity it services.
  • WORKFLOW_TYPE — stores the workflow item type, distinguishing which Workflow process definition governs the associated safety object.
  • LAST_UPDATE_DATE — the date and time of the most recent modification, standard audit metadata used for incremental extraction and change detection.
  • LAST_UPDATED_BY — the application user or identifier responsible for the last change.
  • CREATION_DATE — the timestamp when the workflow association row was first created.
  • CREATED_BY — the user or process that created the row.
  • LAST_UPDATE_LOGIN — the login identifier associated with the last update, supporting audit and session tracing.

Beyond TRANSACTION_ID, the metadata does not document any unique secondary index. OBJECT_ID and WORKFLOW_TYPE are the natural business-key candidates for locating a workflow binding for a specific safety object and item type, but this uniqueness is not confirmed in the supplied documentation.

Common Use Cases and Queries

Typical use cases include diagnosing stalled safety workflows, auditing which workflow item type is attached to a given safety object, and reconciling EAM safety transactions against active workflow instances. Reporting frequently joins this table to Workflow runtime tables to retrieve item keys and status.

A representative query to locate the workflow binding for a safety object:

  • SELECT transaction_id, object_id, workflow_type, last_update_date FROM eam.eam_safety_workflows WHERE object_id = :object_id;

For change-detection extracts, filter on the audit columns:

  • SELECT * FROM eam.eam_safety_workflows WHERE last_update_date >= :since_date ORDER BY last_update_date;

Distinct workflow types can be enumerated to validate configuration coverage across EAM safety objects.

Related Objects

Because the mined relationship data classifies this object as standalone, no foreign keys are documented. The most significant related objects are therefore inferred from its role rather than from enforced constraints:

  • Oracle Workflow runtime tables (item type and item key stores) — joined on WORKFLOW_TYPE and the corresponding workflow key to resolve instance status.
  • EAM safety object tables referenced through OBJECT_ID — the parent safety entities whose workflows are tracked here.
  • EAM maintenance and work order tables that trigger safety workflow creation.
  • Standard audit/system tables resolving CREATED_BY and LAST_UPDATED_BY to user identities.

Integrations should treat TRANSACTION_ID as the reliable unique handle and OBJECT_ID as the practical access path into the safety object graph.