PO-02: PO Approval Workflow Diagnostic

Oracle EBS PO approval workflow failures are among the most operationally disruptive issues in the Procure-to-Pay cycle. When a Purchase Order is submitted for approval, Oracle launches a workflow process instance in the WF_ITEMS table. The workflow routes the approval notification through a hierarchy of approvers defined in the Position Hierarchy or Supervisor Hierarchy, and each approver receives an FYI or Action Required notification in their Oracle Workflow worklist. If the workflow stalls — because an approver's account is inactive, the notification mailer is down, or the approval hierarchy has a gap — the PO sits in IN PROCESS status indefinitely, blocking purchasing activity.

Inactive approver accounts are the most common workflow stall cause. When an approver leaves the organization and their Oracle account is end-dated, any workflow notifications in their queue become orphaned — no one receives them, and the workflow engine does not automatically reroute to an alternate approver unless an escalation rule is configured. PO-02 identifies every active WF_NOTIFICATIONS record in an approver's queue and cross-references the approver's HR record to confirm whether the account is still active.

The approval hierarchy gap is the second major failure mode. Oracle EBS PO approval routing uses either the Position Hierarchy or the Employee/Supervisor Hierarchy defined in HR. When an employee's supervisor assignment is blank — because the employee was transferred and the new supervisor assignment was not entered in HR — the workflow cannot determine the next approver in the chain. The PO approval process terminates with an error and the PO status reverts to INCOMPLETE or stays stuck in IN PROCESS depending on the workflow version.

PO-02 runs a complete approval workflow diagnostic — WF_ITEMS status for the PO approval process, active notifications in each approver's queue, approver account active status and HR supervisor assignment, approval limit validation against the PO amount, escalation rule configuration, notification mailer status, and the full approval history from WF_NOTIFICATION_ATTRIBUTES.

════════════════════════════════════════════════════════════
  ORACLE EBS R12 — PO APPROVAL WORKFLOW DIAGNOSTIC
════════════════════════════════════════════════════════════
  PO Number          : PO-2026-004520
  Amount             : $84,200
  Submitted          : 18-FEB-2026 09:30:00
  Case Number        : PO-492810
  Report Date        : 22-FEB-2026 14:20:15
════════════════════════════════════════════════════════════

[ SECTION 1 — WORKFLOW ITEM STATUS ]        STATUS: ⚠ STALLED
────────────────────────────────────────────────────────────
  WF Item Key        : 4481-PO_APPROVAL
  Item Status        : ACTIVE — 4 days, 4 hrs, 50 min ⚠
  Current Activity   : PO_APPROVE_LIST_APPROVE_MAIN
  Current Approver   : R.DAVIDSON — account INACTIVE since 15-FEB-2026 ✗
  ✗ FAIL: Current approver account inactive — notification stranded

[ SECTION 2 — APPROVAL HIERARCHY ]          STATUS: ✗ FAIL
────────────────────────────────────────────────────────────
  Requester          : J.MARTINEZ — Supervisor: R.DAVIDSON
  R.DAVIDSON         : INACTIVE — end-dated 15-FEB-2026 ✗
  Next Level         : P.CHEN — $200,000 limit — Active ✓
  ✗ FAIL: Approval chain broken at R.DAVIDSON — no rerouting configured

[ SECTION 3 — APPROVAL LIMIT ]              STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  P.CHEN approval limit $200,000 exceeds PO $84,200 ✓

[ SECTION 4 — NOTIFICATION MAILER ]         STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  WF Notification Mailer running ✓

════════════════════════════════════════════════════════════
  DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  APPROVAL STALLED — R.DAVIDSON inactive, notification stranded 4 days
  FIX: Reassign notification to P.CHEN or update J.MARTINEZ supervisor to P.CHEN
════════════════════════════════════════════════════════════

Diagnostic Engine

Runs 35+ checks across WF_ITEMS approval process status, active notifications per approver queue, approver account active status in FND_USER, HR supervisor assignment completeness, approval limit validation against PO amount, escalation rule configuration, and notification mailer service status.

Backup Created

WF tables are Oracle Support territory for direct modification. CONS_BACKUP.WF_NOTIFICATIONS_<case#> is created as documentation. No DML on WF_ITEMS or WF_ITEM_ACTIVITY_STATUSES — corrections go through the Reassign Notification function.

Guided Data Fix

The primary resolution path is the Oracle Workflow Reassign Notification function — PO-02 identifies the notification ID and the correct target approver. HR supervisor assignment corrections are the preventive fix. Direct WF table modification is never performed.

KB Article Generated

Complete KB article generated — PO number, stall duration, inactive approver, notification reassignment performed, HR correction recommended. Upload directly to your knowledge base.

KB-PO-492810-001 · Script: PO-02

PO-2026-004520 Approval Stalled 4 Days — Approver R.Davidson Account Inactive

Module: Purchasing
Platform: EBS R12.2.10
Status: RESOLVED

Symptom

PO-2026-004520 ($84,200) stuck in IN PROCESS for 4 days and 5 hours. Current approver R.Davidson's Oracle account end-dated 15-FEB-2026 as part of offboarding. No escalation rule configured. Notification stranded in inactive account queue.

Root Cause

R.Davidson departed 15-FEB-2026. IT end-dated the FND_USER account as part of the offboarding checklist. The HR supervisor assignment for J.Martinez was not updated from R.Davidson to P.Chen before the account was deactivated. No escalation timeout was configured on the approval workflow.

Tables Affected

WF_NOTIFICATIONS — RECIPIENT_ROLE = DAVIDSON, STATUS = OPEN (4 days, Notification ID: 88412)
FND_USER — END_DATE = 15-FEB-2026 (DAVIDSON — inactive)
PER_ALL_ASSIGNMENTS_F — SUPERVISOR_ID (J.Martinez — still pointing to R.Davidson)

Fix Applied

Notification ID 88412 reassigned to P.Chen via Workflow Reassign Notification. PO-2026-004520 approved by P.Chen 22-FEB-2026 14:45. HR supervisor assignment for J.Martinez updated to P.Chen effective 15-FEB-2026. Escalation rule added: 48-hour timeout routes to next approver.

Prevention

Offboarding checklist updated: HR supervisor reassignments must be updated in Oracle before FND_USER account is end-dated. PO-02 stalled workflow alert should run daily for any PO in IN PROCESS status for more than 48 hours.

Inactive Approver — Notification Stranded

The most common PO approval failure. Approver account end-dated during offboarding while notifications remain in their queue. PO-02 identifies the notification ID and the active approver to reassign to.

Hierarchy

HR Supervisor Assignment Gap

Employee's supervisor not assigned in HR — workflow cannot determine the next approver. PO approval terminates with an error. PO-02 identifies the employee record and the correct supervisor assignment.

Limit

Approval Limit Insufficient

PO amount exceeds the approver's authorization limit. Workflow routes to the next level but there may be no approver at the required limit. PO-02 calculates the required limit and identifies the correct approver.

Service

Notification Mailer Not Running

Workflow notifications generated but not delivered — the mailer service is down. Approvers do not receive email notifications. PO-02 identifies the mailer status and the restart procedure.

Table	Module	Purpose
WF_ITEMS	WF	Workflow process instance — status and duration
WF_ITEM_ACTIVITY_STATUSES	WF	Current activity node and waiting condition
WF_NOTIFICATIONS	WF	Active notifications — recipient, status, age
WF_NOTIFICATION_ATTRIBUTES	WF	Notification attributes — return reason, approval history
FND_USER	FND	Approver account active status and end-date
PER_ALL_ASSIGNMENTS_F	HR	Employee supervisor assignment
PO_HEADERS_ALL	PO	PO authorization status
PO_APPROVAL_LIST_HEADERS	PO	Approval list with limits per approver
PO_ACTION_HISTORY	PO	Complete approval action history

Decision Framework

How Every Fix Decision Is Made

Before any data is modified in a production Oracle database, AP-01 walks through a four-stage decision process. Every condition identified by the diagnostic maps to exactly one resolution path.

First Option — Always

Can the front end fix this?

Oracle's own forms and concurrent programs are always the first option. If the condition can be corrected through Oracle's standard UI — a form, a concurrent program, a setup screen — that path is taken first. No consultant SQL required, no database risk, and the fix is fully supported by Oracle. The diagnostic identifies these conditions explicitly and states the exact front-end navigation path.

✓ Functional Fix

When Front End Is Not Available

Is a direct data fix safe to apply?

When the front-end path is unavailable or would require an unacceptable volume of manual steps, a direct fix is evaluated against explicit criteria. All of the following must be true before proceeding:

→The fix mirrors exactly what Oracle's own code would have done if the underlying condition were corrected

→All dependent tables have been identified and will be updated in the same transaction

→The fix is fully reversible — a single INSERT from the backup table restores the original state

→The environment patch level has been confirmed against the fix logic version

⚡ Direct Fix

Hard Stops — No Exceptions

Does this require Oracle Support?

Certain table areas are never touched directly, regardless of how well the underlying structure is understood. The diagnostic flags these conditions and generates the Service Request documentation:

✗XLA subledger tables — XLA_EVENTS, XLA_AE_HEADERS — incorrect changes corrupt the subledger audit trail in ways undetectable until period close fails or an auditor requests a reconciliation

✗Workflow engine tables — WF_ITEMS, WF_ITEM_ACTIVITY_STATUSES — ad-hoc DML can corrupt the workflow engine state instance-wide

✗Recurring conditions after a fix — indicates a code defect, not a data error. Documented and submitted as a Service Request with a reproducible test case

⚠ Oracle Support

For All Approved Direct Fixes

Backup → Execute → Verify → Document

A timestamped backup table is created and row-count verified before the first UPDATE fires. Explicit parameter confirmation is required — the script will not self-execute. After execution, a verification query confirms the expected state. A complete change record — rows affected, before and after values, database username, timestamp — is written to the FIX_BACKUP_REGISTRY and becomes the primary artifact in the knowledge base entry for this incident.

📋 Documented

Condition Identified	Resolution Path	Notes
Inactive approver — notification stranded in inactive queue	Functional First	Use the Oracle Workflow Reassign Notification function to route the notification to the correct active approver. PO-02 identifies the notification ID and the next active approver in the hierarchy.
HR supervisor assignment missing — hierarchy gap	Functional First	Update the supervisor assignment in HR > People > Enter and Maintain. PO-02 identifies the employee record with the missing or incorrect supervisor and the correct supervisor to assign.
Approval limit insufficient — PO exceeds approver limit	Functional First	Increase the approver's authorization limit via Purchasing > Setup > Approval Authorizations, or resubmit the PO to a higher-level approver directly. PO-02 calculates the minimum limit required.
Notification mailer down — notifications not delivered	Functional First	Restart the Oracle Workflow Notification Mailer via the Workflow Manager in Oracle Applications Manager. PO-02 identifies the mailer service status and the queue depth.
PO stuck in IN PROCESS — no active notification	Oracle Support	When no active notification exists but WF_ITEMS shows ACTIVE, the workflow engine is in an inconsistent state. PO-02 documents the item key and activity status for the Oracle Support SR.
Escalation not configured — workflow never times out	Functional First	Configure escalation rules via Purchasing > Setup > Approval Groups. PO-02 identifies the workflow process and the escalation attribute that needs to be populated.
PO returned by approver — buyer needs to resubmit	Functional First	Buyer corrects the PO based on the return reason in the notification and resubmits. PO-02 identifies the return reason from WF_NOTIFICATION_ATTRIBUTES.
Duplicate approval notifications — PO submitted twice	Oracle Support	Duplicate WF_ITEMS for the same PO indicate a double-submission. PO-02 documents both item keys for Oracle Support — direct WF table cleanup is never performed.

Safeguards

Nothing Executes Without a Safety Net

Before any data fix runs, the script verifies pre-flight conditions and creates a complete verified backup. If any check fails, the script aborts. There is no partial execution path.

Pre-Flight Checks — All Must Pass

✓

POSTED_FLAG = 'N'

Will not modify a posted transaction under any circumstances

✓

ACCOUNTING_EVENT_ID IS NULL

Will not modify rows with an active or pending XLA accounting event

✓

No active database lock

Checks V$LOCK — will not proceed if another session holds a lock on target rows

✓

CONS_BACKUP schema writable

Backup schema must be accessible before any DML is permitted

✓

Explicit confirmation required

Script outputs a confirmation prompt — DML does not execute until consultant enters the case number as the execution parameter

Backup Methodology

Before the first UPDATE fires, the script creates a complete copy of every row to be modified. Tables are named CONS_BACKUP.<TABLE>_<CASE#> and persist permanently after execution.

WF_NOTIFICATIONS

WF_ITEMS

WF_ITEM_ACTIVITY_STATUSES

Row count verified after backup creation. If backup fails for any reason the script aborts without executing any DML. Rollback is a single INSERT from the backup table. No reconstruction required.

PO-02 — Pre-Flight & Backup Verification

════════════════════════════════════════════════════════════
  PRE-FLIGHT SAFETY CHECK — WORKFLOW DIAGNOSTIC
════════════════════════════════════════════════════════════
  PO Number          : PO-2026-004520
  WF Item Key        : 4481-PO_APPROVAL
  NOTE               : WF tables are read-only — no DML performed
  Resolution Path    : Reassign Notification via Oracle WF UI
────────────────────────────────────────────────────────────
  Notification ID    : 88412
  Current Recipient  : DAVIDSON — INACTIVE ✗
  Target Recipient   : P.CHEN — Active, limit $200,000 ✓
────────────────────────────────────────────────────────────
  DIAGNOSIS COMPLETE — Reassign notification 88412 to P.CHEN
════════════════════════════════════════════════════════════
  Creating : CONS_BACKUP.WF_NOTIFICATIONS_492810 (documentation)
  Rows     : 1 row documented ✓
  Registry : FIX_BACKUP_REGISTRY — ID 6058 created ✓
────────────────────────────────────────────────────────────
  BACKUP DOCUMENTED — Proceed via Oracle WF Reassign UI
════════════════════════════════════════════════════════════

Knowledge Base

Every Execution Produces a Record

The knowledge base article is generated automatically from the script's execution output. No manual documentation required. It becomes the institutional record — for the team, for auditors, and for every future engagement in the same environment.

Zero Manual Effort

Every field — environment, tables, before/after values, backup reference, root cause, prevention — is generated from actual execution output. Nothing is written by hand.

Patterns Surface Over Time

The first engagement produces findings. The third produces patterns. Recurring conditions that are invisible as individual incidents become obvious as knowledge base trends.

Survives Staff Turnover

The knowledge base is an institutional record of the Oracle environment. A new manager, a new DBA, or an external auditor can read exactly what happened, what was done, and what prevents recurrence.

KB-PO-492810-001

PO-2026-004520 Approval Stalled 4 Days — Approver R.Davidson Account Inactive

EBS R12.2.10 · Purchasing

● RESOLVED

Symptom

Root Cause

Tables

WF_NOTIFICATIONS — RECIPIENT_ROLE = DAVIDSON, STATUS = OPEN (4 days, Notification ID: 88412)
FND_USER — END_DATE = 15-FEB-2026 (DAVIDSON — inactive)
PER_ALL_ASSIGNMENTS_F — SUPERVISOR_ID (J.Martinez — still pointing to R.Davidson)

Fix Applied

Prevention

R12 Guide (PDF)	Title & Chapter	Detail
120poug.pdf	Oracle Purchasing User's Guide — Ch. 2: Approval, Security, and Control	pp. 2-1 to 2-68: Position hierarchies, approval routing, approval authorization rules
120poug.pdf	Oracle Purchasing User's Guide — Ch. 2: Workflow Options	pp. 1-83 to 1-88: Workflow options for PO approval and notification routing
120poug.pdf	Oracle Purchasing User's Guide — Ch. 2: Submitting a Document for Approval	pp. 2-32 to 2-38: Approval submission, offline approvers, and mass forwarding

PO Approval Workflow Diagnostic

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in PO-02

Backup & Rollback for PO-02

Tables Backed Up — PO-02

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

Inactive Approver — Notification Stranded

HR Supervisor Assignment Gap

Approval Limit Insufficient

Notification Mailer Not Running

Tables Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Ready to Resolve This in Your Environment?

Why This Fails — and What It Costs

What This Script Diagnoses

What the Report Looks Like

The Four-Layer Architecture in PO-02

Backup & Rollback for PO-02

Tables Backed Up — PO-02

Pre-Flight Safety Guards

FIX_BACKUP_REGISTRY Entry

Auto-Generated Knowledge Base Article

What This Script Finds

Inactive Approver — Notification Stranded

HR Supervisor Assignment Gap

Approval Limit Insufficient

Notification Mailer Not Running

Tables Examined

How Every Fix Decision Is Made

Nothing Executes Without a Safety Net

Every Execution Produces a Record

Oracle Documentation References

Related Diagnostic Scripts

Purchase Order Diagnostic

Encumbrance & Budgetary Control

Workflow Engine Diagnostic

Ready to Resolve This in Your Environment?