Search Results wf_items_v




Overview
Explore in AI Chat

Overview

WF_ITEMS_V is a reporting view owned by the APPS schema in Oracle E-Business Suite, classified under the FND — Application Object Library product. Its documented purpose is simply to present a view of WF_ITEMS, the core Workflow runtime item table. In Oracle Workflow, an "item" is the fundamental unit of a running workflow process instance. Each time a business event triggers a workflow — an order being booked, an approval being routed, an expense report being submitted — Workflow creates an item row that tracks that instance from initiation to completion.

WF_ITEMS_V therefore exposes the entire population of workflow item instances across the EBS instance, together with the hierarchical relationships between parent and child items. Its role in reporting and integration is to provide a stable, read-friendly projection of WF_ITEMS that developers and analysts can query for process monitoring, activity auditing, custom dashboarding, and integration extracts. Because it is a thin projection rather than a complex join, it carries a low performance overhead relative to base-table access while offering a cleaner interface for ad hoc SQL and BI Publisher data sources.

For users searching on parent_item_type, this view is the canonical place to resolve that column: it surfaces parent-child item relationships that are otherwise buried in the runtime item table, making it the practical entry point for questions about sub-processes, spawned items, and hierarchical workflow structures.

Underlying Base Objects

The documented base object behind WF_ITEMS_V is a single object: WF_ITEMS, exposed within the APPS schema as a synonym. There are no joins, unions, or aggregations in the view text. The projection is a straight, column-for-column selection of eleven columns from WF_ITEMS:

Because the view adds no filtering and no derived columns, every row in WF_ITEMS_V corresponds one-to-one with a row in WF_ITEMS. Any predicate applied to the view is passed down to the base table, and any index on WF_ITEMS (notably the primary key on ITEM_TYPE plus ITEM_KEY) benefits queries against the view equally. The practical consequence is that WF_ITEMS_V is a naming and abstraction convenience: it isolates consumers from direct dependency on the runtime table while preserving its exact semantics.

Key Columns

The ITEM_TYPE and ITEM_KEY columns together form the unique identifier of a workflow item instance. ITEM_TYPE names the workflow definition (for example, an order or approval process), while ITEM_KEY is the internal instance key within that definition.

USER_KEY is the externally meaningful identifier of the item — typically the primary key of the underlying business entity, such as an order number, invoice identifier, or employee reference. This column is what links a workflow instance back to the transactional record it governs.

ROOT_ACTIVITY and ROOT_ACTIVITY_VERSION identify the top-level activity that initiated the item, allowing queries to group instances by entry point. OWNER_ROLE records the role responsible for the item.

The parent_item_type column, together with PARENT_ITEM_KEY and PARENT_CONTEXT, defines the item's position in a hierarchy. When an item is a sub-process or spawned child, PARENT_ITEM_TYPE holds the item type of the parent instance and PARENT_ITEM_KEY holds that parent's key. For top-level items these columns are null. This trio is the documented mechanism for traversing workflow item trees.

BEGIN_DATE and END_DATE delimit the item's lifetime. A null END_DATE indicates an item still in progress; a populated END_DATE indicates completion.

Common Use Cases and Queries

Typical scenarios include locating the workflow instances associated with a business document, identifying long-running or stalled items, tracing sub-process hierarchies, and feeding workflow status into custom reports or integrations.

To find all items linked to a specific business key:

SELECT item_type, item_key, user_key, begin_date, end_date FROM wf_items_v WHERE user_key = :p_user_key;

To identify all child items spawned by a given parent, using the column the user searched for:

SELECT item_type, item_key, parent_item_type, parent_item_key FROM wf_items_v WHERE parent_item_type = :p_parent_type AND parent_item_key = :p_parent_key;

To find top-level (root) items only, filter on a null parent reference:

SELECT item_type, item_key, user_key, begin_date FROM wf_items_v WHERE parent_item_type IS NULL;

To retrieve still-open items for monitoring:

SELECT item_type, item_key, user_key, owner_role, begin_date FROM wf_items_v WHERE end_date IS NULL AND begin_date < SYSDATE - :p_days;

Because the view mirrors WF_ITEMS exactly, these queries benefit from the base table's indexes and can be combined with WF_ITEM_ACTIVITY_STATUSES queries using ITEM_TYPE and ITEM_KEY to produce full runtime audit reports.