Introduction/ Issue:
In Oracle APEX 26.1, buttons, menu entries, and cards can now perform useful actions without relying on custom JavaScript or complex Dynamic Actions. With the new Trigger Actions feature, developers can declaratively define behaviors such as confirmations, server-side processing, region refreshes, and success messages directly within the component configuration. This makes application development simpler, reduces custom code, and provides a cleaner way to add real functionality to buttons, menus, and cards.
Why Trigger Actions?
In earlier versions of Oracle APEX, buttons and menu entries were mainly used for navigation or page submission, while additional behavior often required custom JavaScript or separate Dynamic Actions. This could make applications harder to maintain and less aligned with modern Content Security Policy (CSP) practices. Oracle APEX 26.1 addresses this with Trigger Actions, which allow developers to define actions such as confirmations, server-side processing, region refreshes, and messages directly on supported components. This provides a simpler, declarative approach using familiar APEX action patterns without the need to create a separate Dynamic Action event.
Buttons Can Now Be Menus
This is a bigger shift than it sounds. A button’s Behavior property now offers three modes instead of one:
- Standard— the classic behavior: page submit, redirect, and similar single-action flows.
- Menu— the button becomes a launcher for a set of menu actions, instead of doing one thing itself.
- Trigger Action— the button executes declarative action logic directly, no separate event needed.
This also renamed the old Link property group to Behavior for Template Component actions and menu entries — a small naming change that reflects how much more these components can now do.
Row Context, Without the Workarounds
This is the part that matters most if you build with Template Components, Cards, or Interactive Reports. When a Trigger Action fires from a row-level action, APEX automatically makes that row’s data available — on both the client and the server:
- On the client:row values are briefly held in a new in-memory session state, accessible via $v(‘COLUMN_NAME’) or &COLUMN_NAME. substitution — then cleared once the action finishes.
- On the server:add the column to Items to Submit, and reference it in PL/SQL with ordinary :COLUMN_NAME bind syntax.
- Column chooser:a picker appears in Page Designer for multi-row regions, letting you control per-column whether it’s “Available on Client” and whether its value is “Protected.”
- Checksum protection:primary keys (and any column you extend it to) passed through the action are checksum-protected, the same mechanism Interactive Grid already relies on.
In practice, this means a “Delete” button on a Cards region can submit that row’s primary key straight to a PL/SQL process — with zero JavaScript involved.
Built-in Protection Against Double-Clicks
Accidental double-clicks on delete or update buttons are a classic source of bugs. Trigger Actions handle this automatically: once an action starts, further clicks on that same row-and-button combination are blocked until the whole action set finishes. It’s scoped per row, so a click on a different row’s button still fires immediately.
There’s no spinner or disabled state built in yet for this initial release — that’s on you to add visually — but the underlying duplicate-submission protection is automatic.
What’s Supported Right Now
The first release focuses on the components developers reach for most often:
- Buttons(with the new Standard / Menu / Trigger Action behavior options)
- Template Component Actions
- Menu Entries
- Native Cards actions
- Interactive Report template component column actions
Buttons keep their existing “Execute Validations” setting, which still applies when Behavior is set to Trigger Action. And nothing old breaks — the existing event-based “Defined by Dynamic Action” option is still there, and a button can have both event-based dynamic actions and Trigger Actions defined side by side in the rendering tree.
Step 1: Open Page Designer in your Oracle APEX application.
Step 2: Create the required page items. In the left pane, select the Button, then create a Trigger Action (Dynamic Action) for it.
Step 3: Add an Execute Server-side Code action and write the INSERT statement for the required table.
Step 4: Save the changes and run the page. Click the button to insert the data into the table.
Conclusion:
This closes one of the more persistent gaps in building interactive, data-driven apps with Template Components and Cards. Instead of a binary choice between “redirect somewhere” or “write JavaScript,” you get the same declarative Dynamic Action model APEX developers already rely on — applied directly to the component that needs it.
It’s also a meaningful step toward CSP compliance, since it removes the need to embed javascript: calls in link targets. If you’ve been building elaborate workarounds with custom events and named actions just to get a button to do real work, this is built for exactly that problem.
