PO-06: PO Approval Workflow Diagnostic (Oracle Fusion)

Oracle Fusion Cloud PO approval workflow operates through BPM (Business Process Management) Worklist rather than the EBS WF_ITEMS engine. When a Purchase Order is submitted for approval in Fusion, an approval task is created in the BPM Worklist and routed to the appropriate approvers based on the Approval Management (AMX) rules configured in the Manage Approval Groups setup. The diagnostic approach is entirely different from EBS — instead of querying WF_ITEMS directly, the consultant uses OTBI Purchasing subject areas, the BPM Worklist API, REST API procurement endpoints, and the Manage Orders approval history screen.

The most common Fusion PO approval failure is a stalled BPM task caused by an inactive approver or a gap in the approval hierarchy. In Fusion, the approval hierarchy is defined in Manage Approval Groups using supervisory hierarchy, job-level hierarchy, or position hierarchy rules. When an approver's account is suspended or the supervisory chain has a gap, the BPM task stops routing and the PO sits in Pending Approval status. The Fusion BPM Worklist shows the task as Assigned to the inactive approver but no action is taken.

Fusion AMX rule misconfiguration is the second major failure source. Unlike EBS where approval limits are set per user in Purchasing > Setup > Approval Authorizations, Fusion uses AMX condition rules that evaluate attributes of the PO at runtime — PO amount, requester business unit, item category, supplier risk tier. When an AMX rule has an incorrect condition expression or references an attribute that returns null, the approval routing can fail to resolve any approver, leaving the PO with no one to approve it.

PO-06 provides a structured Fusion PO approval diagnostic using OTBI Purchasing subject areas for approval status analysis, REST API GET /procurement/purchaseOrders for individual PO approval state, BPM Worklist API for task detail and assignee status, Manage Approval Groups for AMX rule review, and the Fusion approval history screen for the full routing audit trail.

BPM Task Status

BPM Worklist task state for the PO approval process — Assigned, Completed, Withdrawn, Error. Task age and current assignee. Identifies stalled tasks beyond 48 hours with assignee account status check.

REST API Approval State

GET /procurement/purchaseOrders — approvalStatus field. Distinguishes Pending Approval, Pending Buyer Action, Approved, and Rejected states. Provides the PO amount and requester for context.

AMX Rule Evaluation

Manage Approval Groups AMX condition rule review. Identifies rules that resolve no approver for the current PO attributes. Approval amount limit validation against the PO total for each rule level.

Approval History

Full approval routing history from the Fusion approval history screen. Routing path, action timestamps, and return reason for withdrawn approvals. Complete audit trail for the KB article.

════════════════════════════════════════════════════════════
  ORACLE FUSION — PO APPROVAL WORKFLOW DIAGNOSTIC
════════════════════════════════════════════════════════════
  PO Number          : PO-2026-009241
  Amount             : $84,200
  Business Unit      : US Operations BU
  Case Number        : FC-PO-2026-0241
  Report Date        : 22-FEB-2026 14:30:18
════════════════════════════════════════════════════════════

[ STEP 1 — REST API PO STATUS ]             STATUS: ⚠ PENDING APPROVAL
────────────────────────────────────────────────────────────
  PO Status          : Pending Approval — 5 days ⚠
  REST API           : GET /procurement/purchaseOrders/9241
  approvalStatus     : Pending Buyer Action — awaiting approver response

[ STEP 2 — BPM WORKLIST TASK ]             STATUS: ✗ STALLED
────────────────────────────────────────────────────────────
  Task ID            : BPM-TASK-2026-08812
  Assignee           : R.DAVIDSON — account suspended 15-FEB-2026 ✗
  Task State         : Assigned — 5 days without action ⚠
  ✗ FAIL: Assignee account suspended — task cannot be acted on

[ STEP 3 — AMX RULE EVALUATION ]           STATUS: ✓ PASS
────────────────────────────────────────────────────────────
  AMX rules for US Operations BU resolve correctly for $84,200 ✓
  Next approver in chain: P.CHEN — $200,000 limit — Active ✓

[ STEP 4 — APPROVAL HISTORY ]
────────────────────────────────────────────────────────────
  Submitted          : 17-FEB-2026 — J.MARTINEZ
  Routed to          : R.DAVIDSON — 17-FEB-2026
  No action          : 5 days — account suspended ✗

════════════════════════════════════════════════════════════
  FUSION DIAGNOSTIC SUMMARY
════════════════════════════════════════════════════════════
  APPROVAL STALLED — BPM task assigned to suspended account
  FIX: Reassign BPM task to P.CHEN via Manage Tasks or AMX delegate
════════════════════════════════════════════════════════════

Diagnostic Steps

Fusion PO approval diagnostic using REST API GET /procurement/purchaseOrders for approval status, BPM Worklist API for task assignee and state, OTBI Purchasing Orders subject area for stalled approval population analysis, and Manage Approval Groups for AMX rule validation.

Backup Created

Fusion Cloud does not permit direct database access. REST API GET response and BPM Worklist task detail are exported before any corrective action. Provides the before-state record for the KB article and audit trail.

Guided Data Fix

BPM task reassignment via Manage Tasks or AMX delegate configuration is the primary resolution path. AMX rule corrections via Manage Approval Groups for structural issues. All changes through Fusion UI — PO-06 provides the exact navigation path for each condition.

KB Article Generated

Complete KB article generated from REST API and BPM Worklist output — PO number, task ID, stall duration, assignee issue, reassignment performed, AMX rule correction if needed.

Pre-Action Documentation — PO-06

REST API: GET /procurement/purchaseOrders — pre-action export

BPM Worklist Task Detail — exported before reassignment

OTBI: Purchasing Orders — approval status export

Exported before any UI action, ESS resubmission, or FBDI reimport. Provides a point-in-time record of the error state for the KB article and SR documentation if needed.

Pre-Action Verification

Fusion tenant accessibleConfirmed ✓

REST API GET /procurement/purchaseOrders testedResponse saved ✓

BPM Worklist API accessibleConfirmed ✓

OTBI Purchasing subject area availableVerified ✓

Pre-action approval state exportedSaved ✓

Audit Trail Record

CASE_NUMBER<consultant case#>

DIAGNOSTIC_TOOL<OTBI / REST API / BIP / ESS>

ERROR_SNAPSHOT<exported before action>

ACTION_TAKEN<UI path / ESS program / FBDI>

RESULT_VERIFIEDYES ✓

No Direct DB Access — By Design

Oracle Fusion Cloud is a SaaS environment. There is no consultant-accessible Oracle schema, no SQL*Plus connection, and no CONS_BACKUP tablespace. All diagnostic and corrective activity goes through OTBI, REST APIs, BIP reports, ESS programs, and the Fusion UI — the same supported tools Oracle Support uses.

REST API Reference — Endpoints Used in This Diagnostic

All API calls use OAuth 2.0 authentication. The base URL is your Fusion Cloud instance URL. Replace {instanceName} with your tenant name. Obtain the OAuth token via the /oauth/token endpoint using client credentials.

GETPurchase Order Header (Approval Status)

/fscmRestApi/resources/11.13.18.05/purchaseOrders/{POHeaderId}

Path Parameters

POHeaderId integer — Fusion internal PO header ID. Find from PO number via the collection GET with a q filter.

Key Query Parameters

fields POHeaderId,OrderNumber,Status,ApprovalStatus,SubmittedDate,BuyerEmail

Response Fields Read

Status — Open, Closed, Cancelled, Finally Closed

ApprovalStatus — Pending Approval, Approved, Withdrawn, Rejected

SubmittedDate — when the PO was submitted for approval

BuyerEmail — buyer to contact about stalled approvals

GETBPM Worklist Task (Approval Task Detail)

/bpm/api/4.0/tasks

Key Query Parameters

taskType set to POApproval to filter to PO approval tasks only

status ASSIGNED — to find tasks awaiting action

assignee username — to find tasks assigned to a specific approver

keyword PO number — to find the specific PO task

Response Fields Read

taskId — BPM task ID for resubmission or reassignment

status — ASSIGNED, COMPLETED, WITHDRAWN, ERROR

assignee — current assignee username

assignedDate — when the task was assigned (age calculation from this)

taskDefinitionName — confirms this is a POApproval task

NOTE: BPM Worklist API uses the same OAuth 2.0 token as the Fusion REST APIs. Base URL is the Fusion Cloud instance URL with /bpm/ path.

KB-FC-PO-0241-001 · Script: PO-06

Fusion PO-2026-009241 Approval Stalled 5 Days — BPM Task Assigned to Suspended Account

Module: Procurement
Platform: Oracle Fusion Cloud
Status: RESOLVED

Symptom

PO-2026-009241 ($84,200) in Pending Approval status for 5 days. REST API shows approvalStatus = Pending Buyer Action. BPM Worklist task BPM-TASK-2026-08812 assigned to R.Davidson whose account was suspended 15-FEB-2026.

Root Cause

R.Davidson's Fusion account suspended during offboarding. BPM task remains assigned to the suspended account with no automatic rerouting. AMX rules correctly identify P.Chen as the next approver but the task was not auto-reassigned because no reassignment policy was configured.

Tables Affected

REST API: GET /procurement/purchaseOrders/9241 — approvalStatus: Pending Buyer Action
BPM Worklist: Task BPM-TASK-2026-08812 — assignee: DAVIDSON, state: Assigned, age: 5 days

Fix Applied

BPM task BPM-TASK-2026-08812 reassigned to P.Chen via Manage Tasks in Fusion Worklist. PO approved by P.Chen 22-FEB-2026 14:50. Reassignment policy configured in AMX: 48-hour timeout routes to next approver automatically.

Prevention

Fusion offboarding checklist updated: open BPM tasks must be reassigned before account suspension. AMX reassignment policy configured for all approval groups with 48-hour escalation timeout.

BPM Task — Suspended Approver Account

The Fusion equivalent of the EBS inactive approver issue. BPM task assigned to a suspended account — no action possible. PO-06 identifies the task ID and the active next approver for reassignment via Manage Tasks.

AMX

AMX Rule Resolves No Approver

Approval rule condition evaluates to null or resolves no approver for the PO's attributes. PO remains in routing with no one to approve it. PO-06 identifies the failing rule and the null attribute causing the routing failure.

Limit

Approval Limit Below PO Amount

No approver in the AMX hierarchy has a limit sufficient for the PO amount. PO-06 identifies the limit gap and the correct approver or limit to add to the Manage Approval Groups configuration.

Notification

Approval Notification Not Delivered

BPM task exists and is Assigned, but the approver is not receiving email notifications. PO-06 identifies the notification preference configuration and the Fusion email delivery status.

Data Source	Type	Purpose
REST API: /procurement/purchaseOrders	REST	PO approval status, amount, requester
BPM Worklist API	BPM	Task state, assignee, age, approval history
OTBI: Purchasing Orders	OTBI	Stalled approval population — count and aging
Manage Approval Groups	Fusion UI	AMX rule conditions and approval limits
Fusion Approval History	Fusion UI	Full routing history for the PO

Decision Framework

How Every Resolution Decision Is Made

Every condition identified by the diagnostic maps to exactly one resolution path. In Fusion Cloud, all paths go through supported Oracle interfaces — UI, REST API, FBDI, or ESS. Direct database access does not exist in this environment.

First Option — Always

Can the Fusion UI resolve this?

Oracle's own Fusion screens, Scheduled Processes (ESS), and workflow tools are always the first resolution path. Manage Invoices, Manage Suppliers, Manage Accounting Periods, BPM Worklist, Scheduled Processes — the diagnostic identifies the exact navigation path and screen sequence for every condition that can be resolved this way. No third-party tools, no API calls, no risk beyond what Oracle's own UI carries.

✓ Functional First

When the UI Path Is Insufficient

Can a REST API PATCH or FBDI reimport resolve this?

For bulk corrections or conditions not surfaced in the standard UI, Oracle Fusion's public REST APIs and FBDI import templates are the supported programmatic path. A REST API PATCH call to correct an invoice distribution account, an FBDI resubmission with corrected records after an import failure, or a Mass Update via the REST API — these are supported, documented, and reversible through normal Oracle mechanisms. The current state is exported before any API call is made.

→The API endpoint is an Oracle-published, versioned REST resource

→The FBDI template matches the current Fusion release version

→The pre-action state is exported (OTBI report / GET response) before the PATCH or import runs

→The result is verified via a follow-up GET or OTBI query before the case is closed

⚡ API / FBDI

Hard Stops — No Exceptions

Does this require Oracle Support?

Certain conditions in Fusion Cloud cannot be resolved through any customer-accessible interface. The diagnostic flags these and generates the Service Request documentation:

✗ESS job infrastructure failures — job status Error (not Completed with Warnings) indicating an engine-level issue not caused by data

✗Subledger accounting engine errors — Create Accounting failures where the error is in the Oracle accounting engine, not in the source transaction data

✗Recurring failures after correct setup — a condition that returns after a confirmed correct resolution indicates a code defect, submitted as an SR with a reproducible test case

✗Fusion data corruption — records in an inconsistent internal state not reachable through any published API or UI action

⚠ Oracle Support

For All Actions Taken

Export → Act → Verify → Document

Before any UI action, ESS resubmission, REST API call, or FBDI reimport — the current error state is exported via OTBI report, BIP report output, or REST API GET response. After the action, a verification step confirms the expected outcome. The complete sequence — tool used, pre-action state, action taken, result verified — is written into the KB article as the primary record of what was done and why.

📋 Documented

Condition Identified	Resolution Path	Notes
BPM task assigned to suspended/inactive account	Functional First	Reassign the BPM task via Manage Tasks in Fusion Worklist. PO-06 identifies the task ID, current assignee status, and the correct active approver from the AMX hierarchy.
AMX rule resolves no approver — routing failure	Functional First	Review and correct the AMX condition rule via Manage Approval Groups. PO-06 identifies the failing rule attribute and the null-value condition causing the routing failure.
Approval amount limit too low	Functional First	Update the approval limit in Manage Approval Groups > Job Level Hierarchy. PO-06 identifies the approver's current limit and the PO amount requiring approval.
PO approval withdrawn — buyer needs to resubmit	Functional First	Buyer corrects the PO based on the return reason and resubmits via Manage Orders. PO-06 identifies the return reason from the approval history screen.
Approval notification not delivered — Bell/email	Functional First	Check Fusion notification delivery via Manage Worklist > Notification Preferences. PO-06 identifies whether the task exists in BPM but notifications are not being sent to the approver's email.
AMX delegate not configured — approver on leave	Functional First	Configure a delegate via Worklist > Preferences > Delegation Rules. PO-06 identifies the approver with no delegation configured and the PO amount affected.
Multi-level approval loop — PO routes back to requester	Functional First	Review the AMX routing rules for circular references via Manage Approval Groups. PO-06 identifies the routing path from the BPM task history.
BPM task in Error state — engine failure	Oracle Support SR	BPM task status Error (not Assigned or Withdrawn) indicates an engine-level issue. PO-06 documents the task ID and error details for the Oracle Support SR.

Safeguards

Nothing Acts Without a Documented State

Fusion Cloud's SaaS architecture eliminates direct database access — which means every action is a supported Oracle API call, UI operation, or ESS submission. Before any action runs, the current error state is captured. After any action, the result is verified.

Pre-Action Documentation — All Completed First

✓

REST API: GET /procurement/purchaseOrders — pre-action export

Exported before any corrective action is taken

✓

BPM Worklist Task Detail — exported before reassignment

Exported before any corrective action is taken

✓

OTBI: Purchasing Orders — approval status export

Exported before any corrective action is taken

✓

Post-action verification

Follow-up OTBI query or REST GET confirms the expected state before the case is closed

Fusion Audit Trail — What Replaces CONS_BACKUP

In EBS R12, a CONS_BACKUP table provides the rollback point. In Fusion Cloud, the equivalent audit trail is built from three sources that together give a complete before-and-after record:

BEFORE STATE

OTBI report export or REST API GET response saved as the pre-action snapshot

ACTION RECORD

Fusion audit trail (Setup and Maintenance > Audit Reports) captures every UI and API change with user, timestamp, old value, and new value

AFTER STATE

Post-action OTBI query or REST GET confirms the fix — this output becomes the KB article verification artifact

PO-06 — Fusion Diagnostic Framework

════════════════════════════════════════════════════════════
  ORACLE FUSION — PO APPROVAL WORKFLOW DIAGNOSTIC
════════════════════════════════════════════════════════════
  Platform           : Oracle Fusion Cloud (no direct DB access)
  Tools Available    : REST API, BPM Worklist, OTBI, Manage Approval Groups
  Pre-Action Export  : REST API approval state saved before any action
────────────────────────────────────────────────────────────
  Step 1 — REST API  : GET /procurement/purchaseOrders/9241 — status retrieved ✓
  Step 2 — BPM API   : Task BPM-TASK-2026-08812 — assignee R.DAVIDSON suspended ✓
  Step 3 — OTBI      : Purchasing Orders subject area — 5-day stall confirmed ✓
────────────────────────────────────────────────────────────
  DIAGNOSTIC COMPLETE — BPM task reassignment path identified
════════════════════════════════════════════════════════════
  Documentation      : KB article generated from REST API and BPM output
  Fusion Audit Trail : BPM task reassignment logged in Fusion audit trail
  SR Reference       : N/A — resolved via BPM Worklist reassignment
════════════════════════════════════════════════════════════

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-FC-PO-0241-001

Fusion PO-2026-009241 Approval Stalled 5 Days — BPM Task Assigned to Suspended Account

Oracle Fusion Cloud · Procurement

● RESOLVED

Symptom

Root Cause

Tables

REST API: GET /procurement/purchaseOrders/9241 — approvalStatus: Pending Buyer Action
BPM Worklist: Task BPM-TASK-2026-08812 — assignee: DAVIDSON, state: Assigned, age: 5 days

Fix Applied

Prevention

Fusion offboarding checklist updated: open BPM tasks must be reassigned before account suspension. AMX reassignment policy configured for all approval groups with 48-hour escalation timeout.

Documentation Page	Title	Scenario
Implement General Ledger	Getting Started with Financials — Journal Approval Rules	Fusion BPM workflow routing and approval rule configuration
Accounts Payable Manager Job Role	Accounts Payable Manager Job Role	User role and data access setup for Fusion PO approval

PO Approval Workflow Diagnostic (Oracle Fusion)

Why This Fails — and What It Costs

What This Script Diagnoses

Example Completed Worksheet

The Four-Layer Architecture in PO-06

Documentation Before Every Action — PO-06

Pre-Action Documentation — PO-06

Pre-Action Verification

Audit Trail Record

No Direct DB Access — By Design

Auto-Generated Knowledge Base Article

What This Script Finds

BPM Task — Suspended Approver Account

AMX Rule Resolves No Approver

Approval Limit Below PO Amount

Approval Notification Not Delivered

Tables Examined

How Every Resolution Decision Is Made

Nothing Acts Without a Documented State

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

Example Completed Worksheet

The Four-Layer Architecture in PO-06

Documentation Before Every Action — PO-06

Pre-Action Documentation — PO-06

Pre-Action Verification

Audit Trail Record

No Direct DB Access — By Design

Auto-Generated Knowledge Base Article

What This Script Finds

BPM Task — Suspended Approver Account

AMX Rule Resolves No Approver

Approval Limit Below PO Amount

Approval Notification Not Delivered

Tables Examined

How Every Resolution Decision Is Made

Nothing Acts Without a Documented State

Every Execution Produces a Record

Oracle Documentation References

Related Diagnostic Scripts

Purchase Order (Fusion)

AP Invoice Validation (Fusion)

Ready to Resolve This in Your Environment?