Oracle APEX Dynamic Actions: A Practical Guide with Real Examples

Dynamic Actions are how Oracle APEX makes a page react without a full submit: showing a field when a checkbox is ticked, calculating a total as the user types, fetching a customer’s balance when they are selected, or refreshing a report after a modal dialog closes. They are declarative, which means most behaviour can be built without writing JavaScript — but only if you understand how the pieces fit together.

1. The anatomy of a Dynamic Action

Every Dynamic Action has three parts:

• When – the event (Change, Click, Page Load, Dialog Closed, After Refresh…) and the selection it listens to (an item, a button, a region, or a jQuery selector).
• Client-side Condition (optional) – decides whether the True or False actions run, evaluated in the browser at the moment the event fires.
• Actions – one or more steps such as Show, Hide, Set Value, Execute Server-side Code, Refresh or Execute JavaScript Code, run in order.

There is also a Server-side Condition. It is evaluated once when the page is rendered and decides whether the Dynamic Action exists on the page at all. Mixing these two conditions up is one of the most common causes of “my Dynamic Action does nothing”.

2. Example: show a field only when needed

On a sales order page, show the Credit Days field only when the payment type is Credit.

• Event: Change on P10_PAYMENT_TYPE
• Client-side Condition: Item = Value, value CREDIT
• True action: Show P10_CREDIT_DAYS
• False action: Hide P10_CREDIT_DAYS and Clear its value

Tick Fire on Initialization for the Show and Hide actions so the page starts in the correct state when an existing order is opened.

3. Example: calculate a line total

Calculate P10_TOTAL whenever quantity or price changes. Use the Change event with both items in the selection, then a Set Value action of type JavaScript Expression:

(Number($v('P10_QTY')) || 0) * (Number($v('P10_PRICE')) || 0)

This gives instant feedback. Always recalculate stored totals on the server when the page is saved; values calculated in the browser can be changed by the user.

4. Example: fetch data from the database

When a customer is selected, display their outstanding balance. Use Set Value with type SQL Statement or PL/SQL Function Body:

SELECT NVL(SUM(amount_due), 0)
  FROM customer_invoices
 WHERE customer_id = :P10_CUSTOMER_ID
   AND status = 'OPEN'

The critical setting is Items to Submit. The browser must send P10_CUSTOMER_ID to the server, otherwise the bind variable still holds its old session-state value and the query returns the wrong result.

5. Execute Server-side Code

Use this action to run PL/SQL without submitting the page – for example, to mark a task as read or to generate a document number:

:P10_DOC_NO := doc_numbering_pkg.next_number(p_doc_type => 'SO');

Set Items to Submit for inputs and Items to Return for values the code sets, here P10_DOC_NO. Server-side code in a Dynamic Action is not automatically protected by page-level validations, so validate inputs inside the PL/SQL and check authorization where the action changes data.

6. Refreshing regions after a modal dialog

A frequent pattern is a report with an “Add” button that opens a modal page. To refresh the report when the dialog closes:

• Event: Dialog Closed
• Selection: the button or region that opened the dialog
• Action: Refresh the report region

If the report depends on page items, list them in the region’s Page Items to Submit so the refreshed query uses the current values.

7. Confirm before destructive actions

Add a Confirm action as the first step before deleting or posting records. If the user cancels, the following actions do not run. Combine this with an authorization scheme on the button and on the server-side process – a confirmation dialog is a usability feature, not a security control.

8. Wait for results

Actions run in sequence, but some are asynchronous. If a later step depends on a value returned by the server, make sure Wait For Result is enabled on the server call so the next action does not run with stale data.

9. Common mistakes

• Forgetting Items to Submit – the server sees old values.
• Using a Server-side Condition where a Client-side Condition was needed.
• Too many Dynamic Actions on Page Load – each server call adds a round trip. Combine logic or compute it during page rendering instead.
• Duplicating business rules in JavaScript only – always repeat important checks on the server.
• Not using Fire on Initialization for Show/Hide/Enable/Disable, so the page looks wrong when loaded with existing data.

Checklist

• Correct event and selection
• Client-side vs server-side conditions used deliberately
• Items to Submit / Items to Return set on every server call
• Fire on Initialization reviewed
• Confirm action before destructive steps
• Server-side validation and authorization for anything that changes data