By The first time I worked with Oracle APEX dynamic actions, I deleted the wrong setting in Page Designer and spent twenty minutes wondering why my Show action had stopped firing. Nobody warns you that one missing condition can break an entire page. If you are starting from zero, this guide saves you that mistake and a few others.
By the end, you will know what a dynamic action is, the event types behind every one of them, the action types you will reach for most often, and five real examples you can copy into your own application today. If you have never opened Oracle APEX before, start with why Oracle APEX exists first, then come back here.
What Are Oracle APEX Dynamic Actions
An Oracle APEX dynamic action is a rule you build inside Page Designer. It watches for something to happen on a page, checks an optional condition, then runs an action. No JavaScript file, no jQuery selector, no AJAX callback that you have to wire up by hand.
Before dynamic actions existed, showing or hiding a field based on another field’s value meant writing your own JavaScript and binding it to the right DOM event. Dynamic actions replaced that with a point and click interface that generates the same behavior for you. You still have full control through PL/SQL and JavaScript when you need it, but the everyday cases need none of that.
Why Use Oracle APEX Dynamic Actions Instead of JavaScript
Three reasons keep coming up. First, speed. A show or hide rule that used to take fifteen lines of JavaScript now takes thirty seconds in Page Designer. Second, maintenance. The next developer who opens your page, possibly you in six months, reads the dynamic action settings in plain English instead of reverse engineering a script tag. Third, consistency. Every dynamic action follows the same event, condition, action structure, so once you understand one, you understand all of them.
That does not mean JavaScript disappears. You can still drop into a JavaScript or PL/SQL action whenever the built-in options run out, and advanced developers do this constantly. Dynamic actions just remove the JavaScript tax from most of the interactions that do not need it.
The Anatomy of a Dynamic Action
Every dynamic action you will ever build is made of the same six pieces. Once these click, the rest of this guide is just combinations of them.
| Building Block | What It Controls |
|---|---|
| Event | The trigger, such as Change, Click, or Page Load |
| Selection Type | Which item, button, or region the event listens to |
| Condition | An optional rule deciding whether the action should run |
| True Action | What runs when the condition is met, or always if there is no condition |
| False Action | What runs when the condition is not met, optional |
| Affected Elements | The page items or regions the action actually touches |
Think of it as a sentence. When [Event] happens on [Selection], if [Condition] is true, then [Action] runs on [Affected Elements]. Every example later in this guide fits that sentence.
The Four Event Categories in Oracle APEX Dynamic Actions
Oracle groups every dynamic action trigger into four categories: Browser events, Framework events, Component events, and Custom events. Open the Dynamic Actions tab in Page Designer for almost any page and you will already see a default Events group with options like Page Load, Change, Click, and Dialog Closed listed before you even touch a specific item.
| Category | What It Covers | Example Events |
|---|---|---|
| Browser events | Native events fired by the user’s actions in the browser | Click, Change, Key Release |
| Framework events | Events tied to the APEX page lifecycle itself | Page Load, Before Page Submit, Dialog Closed |
| Component events | Events fired by a specific region or component | After Refresh, Row Initialization |
| Custom events | Events you name and trigger yourself in JavaScript | Any name passed to apex.event.trigger |
You do not need to memorize this table. You need to know it exists, so when you are hunting for the right trigger, you are searching the right group instead of scrolling blindly.
The Dynamic Action Types You Will Use Most
An event tells APEX when to look. An action tells it what to do. Out of the dozens of built-in actions, a small handful cover almost every beginner use case.
- Show / Hide, reveals or removes a region or item from the page.
- Enable / Disable, locks an item so the user cannot interact with it.
- Set Value, fills an item using a static value, a SQL statement, a PL/SQL expression, or JavaScript.
- Execute Server-side Code, runs PL/SQL on the database without a full page submit. Older APEX versions called this Execute PL/SQL Code, so do not panic if a tutorial you find still uses that name.
- Execute JavaScript Code, runs custom client-side script when nothing built-in fits.
- Confirm, pops a confirmation dialog and only continues the action chain if the user agrees.
- Refresh, reloads a region’s data without reloading the whole page.
Memorize this list before you memorize anything else in Oracle APEX dynamic actions. Most of your time inside Page Designer will be some combination of these seven.
How Do You Create Your First Dynamic Action in Oracle APEX
Let’s build one from scratch. Say you have a select list called P1_REASON with options like Refund, Exchange, and Other, plus a text item called P1_OTHER_REASON that should only appear when the user picks Other.
- Open your page in Page Designer and click the Dynamic Actions tab.
- Right-click Events and choose Create Dynamic Action, or use the green plus icon.
- Set Name to something descriptive, like “Show Other Reason”.
- Set Event to Change and Selection Type to Item(s), then choose P1_REASON.
- Under Condition, set Type to Value, Operator to Equals, and Value to OTHER.
- Under True Action, choose Show, set Selection Type to Item(s), and choose P1_OTHER_REASON.
- Add a second action set to Hide for the same item, but this time as a False Action, so the field disappears again when the user picks something else.
- Save and run the page. Toggle the select list and watch the field appear and disappear without a single page reload.
That sequence, Event, Condition, True Action, False Action, is the same pattern behind every dynamic action in this guide. Once it feels natural, the rest is just swapping out the action type.
Real Dynamic Action Examples You Can Reuse Today
These five show up in real Oracle APEX applications constantly. Copy the settings, swap in your own item and table names, and you have a working feature in minutes.
Cascading Selects Without a Line of JavaScript
A country list that filters a city list is the classic cascading example. Most select list and popup LOV items in APEX already have a built-in Cascading LOV Parent Item(s) attribute that handles this without any dynamic action at all. Set it on the child item, point it at the parent, and APEX wires the refresh for you.
Build it manually with a dynamic action only when you need extra control, like clearing a third field at the same time. Set Event to Change on the parent item, then add a Refresh true action targeting the child item, plus a Clear Value action on whatever else needs to reset.
Auto-Fill a Field With Set Value From SQL
Picking a department should fill in its location automatically. Create a dynamic action on Change for P1_DEPARTMENT_ID, then add a Set Value true action.
Set Type: SQL Statement
SQL Statement: select location from departments where department_id = :P1_DEPARTMENT_ID
Items to Submit: P1_DEPARTMENT_ID
Affected Elements: Item(s) > P1_LOCATIONNo page submit, no spinner, no extra process. The location field updates the instant the department changes.
Log Every Status Change With Execute Server-side Code
Auditing who changed what is a question every manager eventually asks. Add a dynamic action on Change for P1_STATUS, then choose Execute Server-side Code as the true action.
begin
insert into status_audit_log (record_id, old_status, new_status, changed_by, changed_on)
values (:P1_RECORD_ID, :P1_OLD_STATUS, :P1_STATUS, :APP_USER, sysdate);
end;Set Items to Submit to P1_RECORD_ID, P1_OLD_STATUS, and P1_STATUS so the bind variables have something to read. If you are already centralizing your error handling, this pairs naturally with a centralized error logging framework, since both rely on the same habit of capturing what happened and when.
Confirm Before a Destructive Action
Deleting a row should never be one click away from an accident. Add a dynamic action on Click for your delete button, and set the first true action to Confirm with a message like “Delete this record? This cannot be undone.”
Add a second true action of Execute Server-side Code to run the delete, then a third action of Refresh on the report region. APEX only runs the second and third actions if the user clicks OK. Click Cancel, and the chain stops cold.
Show or Hide a Field Based on a Condition
This is the same pattern from the step-by-step walkthrough above, applied to a payment form. Show a cheque number field only when Payment Method equals Cheque, and hide it for every other value. The smart task tracker I built uses this exact pattern to reveal inline edit controls only on the row a user clicks, instead of opening every row at once.
How Do You Debug a Dynamic Action That Is Not Firing
Start with the browser console, not the database. Most dynamic action failures are wiring problems, not logic problems.
- Check that the Selection Type actually points at the item you think it does. A typo in a static ID is the single most common cause.
- Confirm the event fires at all. Add a temporary Execute JavaScript Code action with
console.log('fired');as the first true action and watch the console. - If a server-side action seems to silently do nothing, check Items to Submit. APEX cannot read a bind variable for an item that was never submitted.
- Use the built-in Debug mode from the Developer Toolbar to see every dynamic action APEX actually executed on that page request, in order.
Nine times out of ten, the fix is one of these four checks, not a deeper bug.
What Mistakes Do Beginners Make With Dynamic Actions
A few patterns repeat across almost every beginner I have helped.
- Forgetting Items to Submit. The PL/SQL runs, but the bind variable is empty because the item’s value never reached the server.
- Stacking too much logic in one action. A single Execute Server-side Code block that does five unrelated things is hard to debug later. Split it.
- Skipping the False Action. A Show without a matching Hide means the field never goes away once it has appeared.
- Ignoring Fire on Page Load. A condition-based Show/Hide that only triggers on Change leaves the page wrong on the very first load, before the user touches anything.
Catch these four early and you skip most of the debugging pain everyone else goes through.
Where Dynamic Actions Show Up in Real Oracle APEX Apps
Once you start looking, dynamic actions are everywhere in a well-built application. The smooth scroll restore behavior on long forms relies on a Page Load dynamic action to put the user back where they left off. Inline editing without opening a modal, like the smart task tracker mentioned earlier, depends on Click and Change events chained together.
Sometimes a built-in action will not cover what you need. Capturing a signature on a touchscreen, for example, is not something Show, Hide, or Set Value can do alone, which is why I ended up building BioSig Pro as a free, open source item type instead. When you hit that wall, a dynamic action is no longer the right tool. A plugin is.
Key Takeaways
Dynamic actions are not a feature you learn once and forget. They are the daily vocabulary of building interactive Oracle APEX pages.
- Every dynamic action is the same sentence: Event, Condition, True Action, False Action, Affected Elements.
- Start with Show, Hide, Set Value, and Execute Server-side Code. They cover most real work.
- Debug with the browser console and APEX Debug mode before you assume the logic is wrong.
- When a built-in action cannot do what you need, that is your signal to look at plugins, not to force a workaround.
Build the show/hide example from this guide on a throwaway page right now. Five minutes from now, dynamic actions stop being theory and start being a tool you actually own.
For the official reference once you are past the basics, Oracle’s Managing Dynamic Actions documentation covers every event and action type in full detail.
Hassan Raza
An Oracle ACE Associate and Senior Oracle Application Developer at S&H Software Solution. I am specialized in Oracle APEX, SQL, and PL/SQL and writes about Oracle development at oraclewithhassan.com
