Search Results wfa_act

Overview

The view APPS.WF_RUNNABLE_PROCESSES_V exposes the subset of Oracle Workflow process definitions that are eligible to be launched (run) at the current point in time. In the Oracle E-Business Suite Release 12.1.1 and 12.2.2 data model, this view is part of the Workflow (WF) schema objects exposed through the APPS synonym layer, and it is commonly queried by concurrent programs, diagnostic utilities, Workflow Monitor style tooling, and custom integrations that need to determine which processes an end user or subsystem may legitimately start.

The view is intentionally narrow. It returns one row per runnable process definition, carrying only the item type, the internal process name, and the user-facing display name. Its role in EBS reporting and integration is therefore that of a reference lookup: it answers the question "which processes can be started right now?" rather than "how is each process structured?". This distinction is important because the broader workflow metadata — activity graphs, attribute assignments, notifications, and functions — lives in other repository views.

Underlying Base Objects

The view is defined over a single documented base object, the view WF_ACTIVITIES_VL. The defining query applies three predicates against that base view, aliased as WFA_ACT:

• WFA_ACT.RUNNABLE_FLAG = 'Y' — restricts the result set to activities that have been marked as runnable.
• WFA_ACT.TYPE = 'PROCESS' — restricts the result set to activities whose type is a process, excluding functions, notifications, and other activity classes.
• SYSDATE BETWEEN WFA_ACT.BEGIN_DATE AND NVL(WFA_ACT.END_DATE, SYSDATE) — enforces effective-dating, so only processes that are active as of the query time are returned. An open-ended END_DATE is treated as still in effect.

Because the definition resolves through WF_ACTIVITIES_VL, the view inherits the translation-aware behaviour of that base view, including the _VL convention whereby the display name is returned in the session's language where a translation exists. No base tables are joined directly; all joins are encapsulated inside WF_ACTIVITIES_VL.

Key Columns

• ITEM_TYPE — the internal name of the workflow item type that owns the process, for example APINV or WFSTD. This is the primary correlation key back to the item type definition.
• PROCESS_NAME — the internal (non-translated) name of the process activity. It is the value expected by Workflow APIs such as WF_ENGINE.CreateProcess and WF_ENGINE.StartProcess.
• DISPLAY_NAME — the translated, user-facing label for the process, sourced from the _VL base view. This is the value suitable for presentation in forms, reports, and list-of-values queries.

Only three columns are projected, and no timestamps, versions, or result codes are exposed, so the view is not suitable for auditing process outcomes or history.

Common Use Cases and Queries

A typical requirement is to populate a selection list of startable processes, optionally restricted to a single item type. The following query retrieves the runnable processes for the WFSTD item type, ordered by display name:

• SELECT item_type, process_name, display_name FROM apps.wf_runnable_processes_v WHERE item_type = 'WFSTD' ORDER BY display_name;

Diagnostic and validation scenarios are equally common. When a process fails to appear in a launch list, a developer will query this view to confirm whether the process is still within its effective date range and whether the runnable flag has been set. A simple existence check is often sufficient:

• SELECT COUNT(*) FROM apps.wf_runnable_processes_v WHERE item_type = :p_item_type AND process_name = :p_process_name;

Because the view already nests WF_ACTIVITIES_VL, custom code should avoid re-joining to that base view unless additional attributes, such as the activity's icon or cost, are genuinely required. Doing so risks duplicate rows and unnecessary cost, particularly in environments with many item types and translated activity names.

Finally, the view is a safe reference for reports that must show only processes that are valid as of the report run date. Its use of SYSDATE means the result set is not deterministic across days, so cached extracts should be refreshed rather than persisted long term.