Search Results eam_isolations_pk




Overview
Explore in AI Chat

Overview

EAM.EAM_ISOLATIONS is the Enterprise Asset Management (EAM) table that stores safety Isolation Definitions. In Oracle EBS 12.1.1 and 12.2.2, an isolation definition represents a formal lockout/tagout (LOTO) or safety isolation record associated with maintaining, servicing, or repairing an asset. The table governs which energy sources must be de-energized, which personnel may approve the isolation, and how long the isolation remains effective.

The object resides in the EAM schema, is marked VALID, and is owned by the EAM product module. From a heuristic Data Vault classification mined from its foreign-key structure, the table is modeled as standalone. In practice this suggests it can be treated as a standalone hub or satellite-like entity, since no inbound or outbound FK links were documented. Its unique business-key candidate (EAM_ISOLATIONS_U01 on ISOLATION_ID) reinforces that ISOLATION_ID is the natural integration key, while EAM_ISOLATIONS_PK also keys on ISOLATION_ID as the surrogate primary key of the physical schema.

Key Information Stored

The physical schema documents 48 columns. The following are the most operationally significant:

  • ISOLATION_ID — surrogate primary key; also the business-key candidate via EAM_ISOLATIONS_U01. It uniquely identifies each isolation definition.
  • ISOLATION_NAME — the human-readable identifier for the isolation definition.
  • ISOLATION_TYPE — classifies the isolation (for example, energy source or isolation method).
  • DESCRIPTION — free-text documentation of the isolation scope or purpose.
  • ORGANIZATION_ID — the inventory/organization (operating unit) context; critical for multi-org security and reporting.
  • PENDING_FLAG — indicates whether the definition is awaiting approval or activation.
  • EFFECTIVE_START_DATE / EFFECTIVE_END_DATE — the validity window during which the isolation applies.
  • APPROVED_BY — the approver responsible for sign-off.
  • USER_DEFINED_STATUS_ID and STATUS_TYPE — the workflow or lifecycle state of the definition.
  • PERMIT_REQUIRED_FLAG — whether a work permit is mandatory before execution.
  • ATTRIBUTE_CATEGORY and ATTRIBUTE1–ATTRIBUTE30 — the descriptive flexfield (DFF) columns used for customer-specific extensions.
  • LAST_UPDATE_DATE, LAST_UPDATED_BY, CREATION_DATE, CREATED_BY, LAST_UPDATE_LOGIN — the standard audit (WHO) columns maintained by Oracle Forms and concurrent processing.

Common Use Cases and Queries

EAM safety isolations are typically reported for compliance, audit, and maintenance planning. A common query retrieves active isolations for a given organization:

  • Querying definitions by name or type: SELECT ISOLATION_ID, ISOLATION_NAME, ISOLATION_TYPE FROM EAM.EAM_ISOLATIONS WHERE ORGANIZATION_ID = :org_id;
  • Identifying pending approvals: filter on PENDING_FLAG = 'Y' or non-null APPROVED_BY.
  • Checking permit requirements: WHERE PERMIT_REQUIRED_FLAG = 'Y';
  • Validity-window reporting: WHERE SYSDATE BETWEEN EFFECTIVE_START_DATE AND EFFECTIVE_END_DATE;
  • Extracting DFF data via ATTRIBUTE_CATEGORY and the ATTRIBUTE1–ATTRIBUTE30 columns.

These patterns support work-order safety preparation, LOTO audits, and asset maintenance compliance dashboards.

Related Objects

The documented metadata classifies the object as standalone, with no inbound or outbound foreign keys. The most significant dependent or logically related objects are therefore inferred from the EAM domain rather than documented FK links, and should be validated against your instance:

  • EAM_ISOLATIONS_PK — primary key constraint/index on ISOLATION_ID.
  • EAM_ISOLATIONS_U01 — unique index enforcing the business-key candidate.
  • EAM_ORGANIZATIONS — organization context joined on ORGANIZATION_ID.
  • EAM_WORK_ORDERS / WIP_EAM_* — maintenance activities that consume isolation definitions.
  • EAM_ASSETS and asset-related EAM tables — the assets protected by an isolation.
  • EAM safety/permit and LOTO-related tables that reference isolation records.

Because the FK structure is documented as standalone, integrators should rely on ISOLATION_ID and ORGANIZATION_ID as the primary correlation keys when building interfaces or reporting models.