Skip to content
Fusion Reference

DOO_HOLD_INSTANCES

Product: DOOtransaction

Hold instances — one row per hold applied to an orchestration order, order line, or fulfillment line, with who applied and released it and when; the "why isn't this line shipping" table

Notes

The parent pointers are prefixed DOO_ here — DOO_HEADER_ID and DOO_LINE_ID, unlike every sibling table — plus FULFILL_LINE_ID; which one is populated depends on the level the hold targets. Active holds are ACTIVE_FLAG = 'Y' with RELEASE_DATE null; released holds remain as history. Hold definitions live in DOO_HOLD_CODES_B (not yet cataloged).

What the badges mean
Product: EGP
Product: the Oracle product family that owns the object — the short code Oracle's Tables and Views documentation lists as the object owner. Fusion is SaaS, so this isn't a database schema; there's no SQL path to the tables at all (see the quirks guide).
master
Data class: what the table holds — master data, transaction documents, control/configuration, interface/staging, or a documented view.

Structural facts — how the table is partitioned, not a trap by itself

BU-striped (ORG_ID)
Rows are scoped to a business unit. The column is still named ORG_ID, but in Fusion it means business unit, not the EBS operating unit — treat any migrated “operating unit” filter as suspect (see the quirks guide).
Per inventory org
Rows are scoped to an inventory organization via ORGANIZATION_ID — always pair it with INVENTORY_ITEM_ID on item-level joins (see the quirks guide).
Set / ledger / named-BU striped
Some tables stripe by a named column instead of ORG_ID: reference data set (SET_ID — see the quirks guide), ledger (LEDGER_ID on the GL journal tables), or a named business-unit column (PRC_BU_ID / REQ_BU_ID in procurement). The table page’s partition line names the column, and the generated SQL anchors on it — never treat these tables as unpartitioned.
Language-striped
The table carries a LANGUAGE column (a _TL translation table or FND_LOOKUP_VALUES) — one row per language. Filter to one LANGUAGE or a join multiplies rows.

Join & extract hazards — verify before you rely on this

Date-effective
This is an _F table — one row per entity per effectivity window, with EFFECTIVE_START_DATE and EFFECTIVE_END_DATE part of the key. Join without a window filter and every fact multiplies by history (see the quirks guide).
View
This is a documented convenience view, not a physical table. Extract through the BICC data store that fronts its base objects instead of assuming the view lands as-is.
In field listings, the Key chip marks a key field — a member of the documented primary key or of a documented unique index.

Extract access

The delivered surfaces that reach this table — the BICC extract data store (PVO) for bulk extraction and the OTBI subject areas for real-time queries. There is no SQL path to the SaaS database.

  • FscmTopModelAM.ScmExtractAM.DooBiccExtractAM.HoldInstanceExtractPVO
    OTBI: Order Management - Order Holds Real Time

    Hold Instances data store — keyed on HoldInstanceHoldInstanceId, mirroring HOLD_INSTANCE_ID. Hold-code definitions ride the companion HoldCodeExtractPVO / HoldCodeTLExtractPVO stores.

    Oracle data-store documentation (opens in new tab)

Fields

13 fields · 1 key

13 fields.

Table fields: position, field name, description, data type, and flags. 13 fields.
#FieldDescriptionTypeFlags
1HOLD_INSTANCE_IDSurrogate key of the hold instanceNUMBER
Key
2HOLD_CODE_IDThe hold-code definition this instance appliesNUMBER
3DOO_HEADER_IDOrder header the hold targets — note the DOO_ prefix, unlike sibling tablesNUMBER
4DOO_LINE_IDOrder line the hold targetsNUMBER
5FULFILL_LINE_IDFulfillment line the hold targetsNUMBER
6ACTIVE_FLAGWhether the hold is currently active — released holds remain as historyVARCHAR2
7APPLY_DATEWhen the hold was placedDATE
Filter date
8RELEASE_DATEWhen the hold was released — NULL while activeDATE
9APPLY_USER_IDUser who requested the holdVARCHAR2
10RELEASE_USER_IDUser who released the holdVARCHAR2
11APPLY_SYSTEMSystem that requested the holdVARCHAR2
12HOLD_RELEASE_REASON_CODEReason code recorded at releaseVARCHAR2
13HOLD_COMMENTSComments entered when applying the holdVARCHAR2

Field provenance: hand-curated. 1 key field.

Boilerplate SQL

Starting point for reading the BICC-landed copy of DOO_HOLD_INSTANCES on Databricks — real DATE columns need no conversion, and the org anchor and the LAST_UPDATE_DATE watermark (the column incremental BICC extracts key on) are already in place. Set your Unity Catalog location, schema, and org values below; they’re substituted into the SQL and the copy button.

Query parameters

6 parameters not filled: <catalog>, <schema>, <HOLD_INSTANCE_ID>, <DATE_FROM>, <DATE_TO>, <watermark>

-- ============================================================
-- Table  : DOO_HOLD_INSTANCES — Hold instances — one row per hold applied to an orchestration order, order line, or fulfillment line, with who applied and released it and when; the "why isn't this line shipping" table
-- Purpose: Column-selected read of DOO_HOLD_INSTANCES — auto-generated from field metadata
-- Grain  : One row per HOLD_INSTANCE_ID
-- Notes  : Auto-generated skeleton for Oracle Fusion Cloud data landed in your lakehouse by a BICC extract — there is no SQL path to the SaaS database. Column names follow Oracle's table documentation — if your landed data still carries PVO attribute headers, map names first; see quirks #pvo-drift. Dates are real DATE/TIMESTAMP columns — no conversion needed. WHO audit columns omitted (see the quirks guide); the optional LAST_UPDATE_DATE watermark filter supports incremental extracts.
-- ============================================================
SELECT
  t.HOLD_INSTANCE_ID AS "Surrogate key of the hold instance",
  t.HOLD_CODE_ID AS "The hold-code definition this instance applies",
  t.DOO_HEADER_ID AS "Order header the hold targets — note the DOO_ prefix, unlike sibling tables",
  t.DOO_LINE_ID AS "Order line the hold targets",
  t.FULFILL_LINE_ID AS "Fulfillment line the hold targets",
  t.ACTIVE_FLAG AS "Whether the hold is currently active — released holds remain as history",
  t.APPLY_DATE AS "When the hold was placed",
  t.RELEASE_DATE AS "When the hold was released — NULL while active",
  t.APPLY_USER_ID AS "User who requested the hold",
  t.RELEASE_USER_ID AS "User who released the hold",
  t.APPLY_SYSTEM AS "System that requested the hold",
  t.HOLD_RELEASE_REASON_CODE AS "Reason code recorded at release",
  t.HOLD_COMMENTS AS "Comments entered when applying the hold"
FROM <catalog>.<schema>.DOO_HOLD_INSTANCES t
WHERE
  1 = 1  -- no automatic partition anchor on this table; the filters below are optional
  -- AND t.HOLD_INSTANCE_ID = <HOLD_INSTANCE_ID>
  -- AND t.APPLY_DATE >= DATE '<DATE_FROM>'
  -- AND t.APPLY_DATE <= DATE '<DATE_TO>'
  -- AND t.LAST_UPDATE_DATE >= TIMESTAMP '<watermark>'  -- the column incremental BICC extracts key on
ORDER BY t.HOLD_INSTANCE_ID;

Verified September 2026 · docs release 26C

Column names differ in BICC extracts — see PVO header drift.

Relationships

Diagram of 1-hop neighbors — join details below. FND lookup decode and translation edges are highlighted; they’re the joins newcomers most often get wrong.

Join details

  • DOO_HOLD_INSTANCESDOO_HEADERS_ALLforeign key · N:1
    ON DOO_HOLD_INSTANCES.DOO_HEADER_ID = DOO_HEADERS_ALL.HEADER_ID
  • DOO_HOLD_INSTANCESDOO_LINES_ALLforeign key · N:1
    ON DOO_HOLD_INSTANCES.DOO_LINE_ID = DOO_LINES_ALL.LINE_ID
  • DOO_HOLD_INSTANCESDOO_FULFILL_LINES_ALLforeign key · N:1
    ON DOO_HOLD_INSTANCES.FULFILL_LINE_ID = DOO_FULFILL_LINES_ALL.FULFILL_LINE_ID

Browse more Order Management tables

More Order Management tables

Maintained by Summit Analytics, a supply chain analytics practice. The tools and references are free — the consulting is selective.

Part of the Summit Analytics reference library.

Work with the practice

Not affiliated with or endorsed by Oracle. Oracle and Oracle Fusion Cloud Applications are registered trademarks of Oracle and/or its affiliates.