Events & Actions Overview

How Events and Actions Work

You make an app interactive by attaching events to a component (or to the page itself) and giving each event one or more actions. An event is the trigger — a click, a value change, a page load. An action is what runs in response — navigate, run a data source, set a variable, open a modal.

You configure interactions in a component's Interactions section: click + (Add Interaction), choose the Event, then choose the Action. For page-wide triggers, open the page settings and use the Events list in its Interactions section. Actions on the same event run in order, top to bottom.

Note: Where to configure: Application builder → select a component → its Interactions section in the properties panel → + (Add Interaction) → Event and Action. Follow-up actions go under Callbacks → On Success / On Failure.

Event Node Anatomy

Internally, each event-action pair is stored as a node in the component's events array. Understanding this shape helps when reading generated configurations or debugging unexpected behavior.

JSON — event node structure

{ "eventType": "onClick", "id": "Evt_6VRjl", "action": { "actionType": "showNotification", "payload": { "type": "success", "title": "Saved successfully" }, "id": "act_674C5" } }

Key facts about the node shape:

• eventType — the exact camelCase event key (e.g. onClick, onChange, onSubmit). The click event is always onClick — lowercase "on", uppercase "C".

• id — platform-minted identifier beginning with Evt_ or evt_.

• action — a single action node. Multiple actions on the same event are sibling entries in the array sharing the same eventType, executed in array order.

Event Types

Each component exposes the events that make sense for it. The table below covers the most common ones.

Action Catalog

The action picker groups actions by category. The list below shows every action on a page, with the label you see in the builder. Some actions appear only in mobile apps, and integration actions appear only when that integration is enabled for the app. App-level events offer a smaller set.

Data Actions

Navigation Actions

Block Control Actions

State Actions

Event Actions

User Interaction & Sharing Actions

Mobile Actions (mobile apps only)

Apps & Integrations (shown only when the integration is enabled)

Action Node Structure

Every action — regardless of type — follows the same node shape:

JSON — full action node

{ "actionType": "showNotification", "payload": { "type": "success", "title": "Record saved", "description": "Changes were applied." }, "id": "act_674C5", "runCondition": { "type": "filter", "payload": { "operator": "AND", "filters": [ { "property": "{{ var_isAdmin['value'] }}", "filter": { "operator": "EQUAL", "value": "true" } } ] } }, "onSuccessActions": [ { "actionType": "navigate", "payload": { "path": "/dashboard" }, "id": "act_abc1" } ], "onErrorActions": [ { "actionType": "showNotification", "payload": { "type": "error", "title": "Failed" }, "id": "act_abc2" } ] }

Sequential vs Callback Execution

UnifyApps gives you three ways to chain actions. Choose based on whether subsequent actions depend on the prior action's success:

1. Sequential Steps (same event)

When you add multiple actions to one event, they run as sibling entries in array order. Use this for "do A then B" where B does not depend on whether A succeeded.

Pattern — sequential actions on onClick

{ "events": [ { "eventType": "onClick", "id": "Evt_001", "action": { "actionType": "setPageVariable", "payload": { "variableId": "var_abc", "operationDetails": { "operation": "SET", "value": "active" } }, "id": "act_001" } }, { "eventType": "onClick", "id": "Evt_002", "action": { "actionType": "showNotification", "payload": { "type": "success", "title": "Done" }, "id": "act_002" } } ] }

2. Success/Failure Callbacks

Use onSuccessActions and onErrorActions on an action node when the follow-up only makes sense after the parent succeeds or fails. For example: save a record → on success navigate away, on failure show an error.

Warning: One level only. Callback actions cannot carry their own onSuccessActions/onErrorActions. The builder enforces this limit. A plain sibling event entry is not a second stage: it runs whether or not the earlier action succeeded. For a stage that depends on a data source call, put it on the data source's own On Success / On Failure events (see Data Source Events below). Otherwise, have the callback write a page variable and gate the later sibling entry with an Only run when condition on that variable.

3. Data Source Events

When you want to react to an async data source completing, put the follow-up actions on the data source's own onSuccess / onFailure events — not inside the action that triggered the data source. This is the correct pattern for "call an API, then show a success toast."

Conditional Execution

Each action supports an Only run when condition, stored as a runCondition — a condition object that gates whether the action runs. If the condition evaluates to false, the action is skipped without error.

The condition object takes one of two forms:

Form 1 — boolean literal

{ "type": "boolean", "payload": true }

Form 2 — filter group (role-based gate)

{ "type": "filter", "payload": { "operator": "AND", "filters": [ { "property": "{{ userContext.roles.some((role) => role.name === 'admin') }}", "filter": { "operator": "EQUAL", "value": "true" } } ] } }

Execution Strategy: Delay, Debounce, Throttle

Each action can have an execution strategy that rate-limits when it fires:

Managing Events and Actions

In the builder's Interactions panel you can:

• Reorder actions by dragging within the same event.

• Copy an action to reuse its configuration elsewhere.

• Disable an event or action without deleting it — disabled items are skipped at runtime and shown dimmed with a tooltip. Use this to temporarily switch off behavior while testing.

• To ask for confirmation before a destructive action runs, open a Modal with Control Modal instead, and put the destructive action on the modal's confirm button.

Tip: Put a navigate or navigateToPage action last in a sequential chain. The runner continues executing later nodes even after a same-tab navigation (it does not cancel the loop), so a navigate mid-chain can lead to unexpected behavior.

End-to-End Example: Save & Navigate

A button that saves a record, shows a success toast, then navigates to a list page — or shows an error on failure. Trigger Data Source only reports that it started the data source, not whether the save worked, so the follow-up actions go on the data source's own events:

1. On the button: Add an On Click interaction with a Trigger Data Source action for ds_saveRecord.

2. On the data source's On Success event: Add a Show Snackbar action ("Record saved"), then a Go to Page action for the list page.

3. On the data source's On Failure event: Add a Show Snackbar action with type error ("Save failed").

Complete event handler — save button

{ "eventType": "onClick", "id": "Evt_saveBtn", "action": { "actionType": "controlDataSource", "payload": { "dataSourceId": "ds_saveRecord", "method": "trigger" }, "id": "act_save" } }

Data source event handlers — ds_saveRecord

These are set in the data source's Event Handlers section and stored on the data source:

{ "callbacks": { "successEvents": [ { "eventType": "onSuccess", "id": "Evt_saved", "action": { "actionType": "showNotification", "payload": { "type": "success", "title": "Record saved" }, "id": "act_toast" } }, { "eventType": "onSuccess", "id": "Evt_goList", "action": { "actionType": "navigateToPage", "payload": { "pageId": "e_recordListPage" }, "id": "act_goList" } } ], "failureEvents": [ { "eventType": "onFailure", "id": "Evt_failed", "action": { "actionType": "showNotification", "payload": { "type": "error", "title": "Save failed" }, "id": "act_error" } } ] } }