When building Human Task workflows in modern Oracle APEX releases, the built-in Unified Task List and Task Details Page generators save substantial development time. However, things can get tricky when you customize these generated pages—specifically when adding custom Form regions alongside standard human task controls.

A frequent and confusing bug occurs when a user clicks Release in the Actions menu: the task successfully unclaims, but APEX redirects to an error page stating that the task was not found. Here is a breakdown of why this happens and how to fix it properly.

The Symptom: Primary Key URL Swapping

Before releasing, your URL typically looks like this:

f?p=100:12:SESSION:::12:P12_TASK_ID:10280006769377628

Upon clicking Release, APEX submits the page with the request RELEASE, successfully executes the Human Task - Manage process, but then reloads the page with the wrong parameter:

f?p=100:12:SESSION:::12:P12_EQUIPMENTNR:10000084

Because P12_TASK_ID is now null, the native Task Details region fails to locate the task, throwing the "Task not found" error.

Why Does APEX Replace the Task ID?

When you add an editable Form region to an existing page, Oracle APEX generates or modifies two critical components behind the scenes:

  • Form Initialization / Primary Key Binding: The Form region designates P12_EQUIPMENTNR as the primary key.
  • Page Branches: Form creation wizards often automatically inject an After Submit branch targeting the current page (Page 12) or the parent page. This branch is preconfigured to pass the newly created Form's Primary Key item (P12_EQUIPMENTNR) rather than your Workflow Task parameter (P12_TASK_ID).

Because the Release action menu item uses #action$release?do=submit, APEX treats the interaction as a full page submission with :REQUEST = 'RELEASE'. Once the Release process completes, the execution falls through to the page's After Submit Branches, which fire and rewrite the query parameters using the Form's PK item.

How to Fix the Issue

Solution 1: Redirect to the Unified Task List on Release (Recommended)

From a UX perspective, reloading the Task Details page after releasing a task is rarely desirable. When a user releases a task, they are giving up ownership; the task returns to the pool of unassigned or assigned tasks. The cleanest workflow is to redirect the user back to the Task Inbox / Unified Task List.

  1. In Page Designer, navigate to the Processing tab (the left tree icon).
  2. Under Branches, right-click and select Create Branch.
  3. Set the following attributes:
    • Title: Go to Unified Task List
    • Target: Page containing your Unified Task List (e.g., Page 1 or Page 10).
    • Server-side Condition > Type: Request = Value
    • Value: RELEASE
  4. Ensure this branch evaluates before any default form branches.

Solution 2: Update the Branch to Re-Pass the Task ID

If business requirements dictate that the user must remain on Page 12 after releasing the task (e.g., to view it in read-only mode), update the existing reload branch:

  1. Locate the Branch that fires after submission on Page 12.
  2. In the Link Builder Target modal:
    • Set Page: 12
    • In Set Items, ensure Name: P12_TASK_ID and Value: &P12_TASK_ID.
    • Remove P12_EQUIPMENTNR from the item mappings.
  3. Save and re-test the Release flow.

Solution 3: Check Form Region "Reload on Submit"

If there are no explicit branches visible in your Page Designer tree, check the Form - Automatic Row Processing process under the Processing tab:

  • Look for Return Primary Key(s) after Insert or target redirection settings on the Form region.
  • Make sure that the Form DML process has a Server-side Condition preventing it from running when REQUEST IN ('RELEASE', 'CLAIM', 'CANCEL'), ensuring that row processing only runs on your custom save actions (e.g., SAVE or SUBMIT).

Summary

When mixing manual Form regions with generated Human Task pages in Oracle APEX, the automatic branch configuration generated by the Form wizard will conflict with task parameters. Conditionally routing the RELEASE request back to your task inbox or correctly preserving P12_TASK_ID in post-submit branches completely eliminates the error.