Search Results notification_status




Overview

WF_ITEM_ACTIVITIES_HISTORY_V is a view owned by the APPS schema in Oracle E-Business Suite, registered under the FND — Application Object Library product. The view presents the complete activity history for workflow items processed by the Oracle Workflow engine. Where transactional tables such as WF_ITEM_ACTIVITY_STATUSES store only the current state of a workflow activity instance, this view consolidates historical and in-flight activity records so that administrators and developers can reconstruct the lifecycle of any workflow item, from initiation through completion, error, cancellation, or deferral.

The view is implemented as a UNION ALL over item activity status records, including both the live status table and its history counterpart. This construction allows it to expose superseded activity states alongside current ones. Because the view joins definition metadata (activity names, display names, parent process context, notification status, and result codes), it delivers a self-contained, human-readable audit trail rather than raw numeric identifiers. The view is commonly surfaced through the Workflow Monitor (WFMON) administrative interface and is a standard target for custom reporting and integration queries in both 12.1.1 and 12.2.2.

Underlying Base Objects

The documented base objects for this view are:

  • WF_ITEM_ACTIVITY_STATUSES (synonym) — primary source of per-activity-instance runtime status, begin/end timestamps, execution time, notification ID, and result codes.
  • WF_ITEM_ACTIVITY_STATUSES_H (synonym) — the historical counterpart, supplying earlier activity states folded in via UNION ALL.
  • WF_PROCESS_ACTIVITIES (synonym) — links each activity instance to its parent process instance and resolves the process activity definition.
  • WF_ACTIVITIES_VL (view) — the activity definition view (joined twice), supplying activity names, display names, types, and definition-level begin/end dates, and providing the parent activity context.
  • WF_NOTIFICATIONS (synonym) — outer-joined on GROUP_ID to the activity notification ID, supplying notification status and recipient role.
  • WF_CORE (package) — supplies ACTIVITY_RESULT and TRANSLATE functions used to derive readable result and status text.
  • WF_DIRECTORY (package) — supplies GETROLEDISPLAYNAME for resolving recipient role display names.

The joins are predominantly inner joins that resolve each activity instance against its definition and parent, with a single outer join to WF_NOTIFICATIONS so that activities without notifications are still reported.

Key Columns

Common Use Cases and Queries

The most frequent requirement is to retrieve the audit trail of a specific workflow item, ordered chronologically. Because the user searched for "activity_status," the derived status column is central to most queries.

To list the complete history of one item, filtering on the derived status:

  • SELECT item_type, item_key, activity_name, activity_status, begin_date, end_date, duration
  • FROM wf_item_activities_history_v
  • WHERE item_type = :p_item_type AND item_key = :p_item_key
  • ORDER BY begin_date;

To identify activities that are still active (including those mapped from DEFERRED, WAITING, or NOTIFIED) and have been running unusually long:

  • SELECT item_type, item_key, activity_name, activity_status, duration
  • FROM wf_item_activities_history_v
  • WHERE activity_status = 'ACTIVE' AND duration > 3600
  • ORDER BY duration DESC;

To reconcile errored activities against their notifications and recipient roles for a given workflow type:

  • SELECT item_key, activity_name, activity_status, notification_status, recipient_role_name
  • FROM wf_item_activities_history_v
  • WHERE activity_status = 'ERROR' AND item_type = 'WFERROR';

Because the view derives ACTIVITY_STATUS and DURATION dynamically, and applies translation functions in the status display column, reports should be written against ACTIVITY_STATUS rather than ACTIVITY_STATUS_DISPLAY when filtering programmatically. Queries joining the view to large item populations should filter on ITEM_TYPE and date ranges to limit the UNION ALL scan.