Build Actionflows

Create an Actionflow and choose an execution mode

Open Action → Actionflow, create an Actionflow, and give it a descriptive name. The execution mode determines transaction and timeout behavior:

• Synchronous: Database-operation nodes can commit or roll back together, but the entire Actionflow is subject to the synchronous runtime cap.
• Asynchronous: The Actionflow does not provide one transaction across all database nodes and is suited to longer-running work. Actionflows containing AI Agent nodes must be asynchronous.

Execution mode affects transactions and timeouts. See Execution modes and transactions and Timeout policy.

Define inputs, outputs, and variables

• Inputs: Values the caller must provide. Every node in the Actionflow can reference them.
• Outputs: Values returned to the caller after the Actionflow completes.
• Actionflow variables: Temporary values shared inside the Actionflow. Update them with Assign Actionflow Variable, commonly to carry results out of a branch.

Use clear, stable names and make sure each type matches the value supplied or consumed by callers.

Add nodes

Select + to add Database, API, Actionflow, AI Agent, Condition, For each, Run code, or other nodes in business order.

A later node can read an earlier node’s result through:

Actionflow data → Node name → Field name

Data flows from nodes that have already executed to later nodes. Results created inside a condition or loop have branch scope. To use a value outside that branch, assign it to an Actionflow variable first.

For every available node and its parameters, see Actionflow nodes.

Add triggers

An Actionflow can have multiple Triggers:

• Scheduled: Run at a configured time or Cron schedule.
• Database change: Run when matching database data changes.
• Webhook: Run when an external system calls its endpoint. Payment callbacks are a specialized Webhook use case.

Bind each Trigger’s data to the inputs required by the Actionflow. See Backend Triggers for configuration details.

An Actionflow that is called only by a page, the Runtime API, or another Actionflow does not need a Trigger.

Set permissions

Under Settings → Permissions, select which roles may call the Actionflow.

Permissions apply to:

• Calls made by a frontend Call Actionflow action.
• Direct calls made through the Runtime API.

Permissions do not block Scheduled, Database change, or Webhook Triggers, or server-side calls from another Actionflow.

Publish changes

Actionflow edits are saved automatically. Both operations below publish the latest Actionflow configuration:

• Update preview: Refreshes the frontend preview and publishes Actionflow, API, AI Agent, and other backend configurations.
• Sync changes: Publishes Actionflow, API, AI Agent, and other backend configurations without refreshing the frontend preview.

Publishing an Actionflow affects live apps immediately. A published frontend calling that Actionflow will execute its latest published configuration. Review the impact on both preview and live apps before changing an existing flow.

Call an Actionflow

An Actionflow can be called in the following ways:

• Trigger: Configure a Scheduled, Database change, or Webhook Trigger. One Actionflow can have multiple Triggers.
• Page or component: Add a Call Actionflow action under a Trigger, choose the Actionflow, and bind its inputs.
• Another Actionflow: Add a Call Actionflow node, choose the Actionflow, and bind its inputs. Later nodes can read the outputs returned by that node.
• Runtime API: Call an Actionflow or retrieve asynchronous task results in code. See Runtime API Reference — Actionflows.

When called from a page or component, the action enters On success after the Actionflow completes and On failure if execution fails. Under On success, read Actionflow outputs from:

Context → Action results → Call Actionflow → Field name

View runtime logs

Open Project details → Runtime logs to inspect execution status, node inputs and outputs, and errors. Filter by Actionflow ID to locate a specific flow.