Actions & Workflows

Actions are server-side workflows that execute in response to user interactions. They are the backbone of your app's business logic -- handling form submissions, data processing, email notifications, and API integrations.

Two Types of Actions

User-Managed (Reusable) Actions

Created from the Actions tab in your app. These are named, standalone workflows with a slug and optional input definitions. They can be called from:

• Widget events (button clicks, form submissions)
• Other actions via the Run Action node
• Multiple components throughout your app

Reusable actions are ideal for shared logic like "create a new task", "send a notification", or "update user profile".

Inline Actions

Defined directly on a widget event in the UI Builder's Events tab. The pipeline is stored as part of the component layout. Use inline actions for simple, one-off logic that only applies to a single widget event.

Creating a Reusable Action

1. Navigate to your app and click the Actions tab.
2. Click Create Action.
3. Enter a Name and Slug (same slug rules as apps: lowercase, letters/digits/underscores, must start with a letter).
4. Click Create to open the Workflow Builder.

The Workflow Builder

The Workflow Builder is a visual pipeline editor similar to the data source builder, but with access to all 49 node types. You build a chain of nodes that process data sequentially:

Validate Input -> Query Table -> If/Else -> Save Row -> Send Email -> Result

Common Patterns

Form submission handler:

1. Validate -- check required fields, format constraints
2. Sanitize -- clean user input (trim, strip tags, etc.)
3. Rate Limit -- prevent abuse (e.g., max 5 submissions per minute)
4. Save Row -- write to your database table
5. Send Email -- notify the admin or the submitter
6. Result -- return a success/error message to the frontend

Data processing workflow:

1. Table Query -- fetch data from a source table
2. Filter -- select rows matching criteria
3. Mapping -- transform fields
4. For Each -- iterate and run a sub-action per row
5. Result -- return the processed data

Inputs

Reusable actions can define inputs in their configuration. Inputs are named parameters that callers must provide. In the workflow, input values are accessible as row.input_name.

When a form triggers an action, all form field values are automatically passed as inputs.

How Actions Execute

Actions run entirely on the server. When a user triggers an action (e.g., submitting a form or clicking a button):

1. The browser sends an AJAX request to the WordPress REST API.
2. WordPress verifies the nonce (CSRF token) and checks user capabilities.
3. The action pipeline executes server-side -- no pipeline logic is ever sent to the browser.
4. The result is returned as a JSON response.
5. The frontend updates accordingly (shows success message, refreshes data, navigates, etc.).

This architecture means:

• Action definitions are never exposed to the frontend. Users cannot inspect or tamper with your workflow logic.
• Validation and sanitization happen server-side, even if you also validate on the client.
• Database credentials and API keys remain on the server.

Attaching Actions to Widget Events

In the UI Builder, select a widget and open the Events tab. For each available event:

1. Choose Inline to define a pipeline directly, or Action to select a reusable action by slug.
2. For reusable actions, map the inputs -- typically the form values or row data are passed automatically.

Common Widget Events

Widget	Events
Button	onClick
Form Container	onSubmit
Text Input	onChange, onBlur, onFocus
Select	onChange
Checkbox	onChange
File Upload	onChange
Container	onClick
Repeater	onClick
Listing Grid	onClick

Tips

• Always validate and sanitize user input at the start of your action pipeline, even for logged-in users.
• Use Rate Limit on public-facing forms to prevent spam.
• Prefer reusable actions over inline actions when the same logic is needed in multiple places.
• Use the Debug node during development to inspect intermediate pipeline data.
• Keep actions focused -- each action should do one thing well. Chain them with Run Action for complex workflows.