Actions¶
Overview¶
Actions define what happens when a user interacts with a page — clicking a table row, pressing a button, or submitting a form. Each block can have one or more actions attached to it.
Actions are configured in the actions array of a block definition:
{
"blockType": "table",
"actions": [
{
"id": "action-1",
"type": "navigate-to-page",
"label": "View Details",
"targetRef": "order-detail",
"activation": "row-click"
}
]
}
Action types¶
| Action Type | Description | Common Use |
|---|---|---|
navigate-to-page | Redirects to another page, optionally passing data as query params | List-to-detail navigation |
invoke-trigger | Invokes an on-demand function trigger | Run business logic, call external APIs |
create-record | Creates a new record in a collection | Form submission |
update-record | Updates an existing record | Inline edit, status change |
start-orchestration | Starts an automation workflow | Multi-step approval, provisioning |
enqueue-job | Enqueues a scheduled job | Deferred processing |
open-modal | Opens a modal block by ID | Confirmation dialogs, detail previews |
close-modal | Closes an open modal by ID | Cancel buttons inside modals |
Deprecated types
execute-function and run-query are deprecated and should not be used in new page definitions. Use invoke-trigger instead of execute-function.
Allowed actions by block type¶
Not every action type is available on every block. The table below shows which action types are supported:
| Block Type | Allowed Actions |
|---|---|
table (data-table) | navigate-to-page, invoke-trigger |
field-display | invoke-trigger, navigate-to-page |
related-list | navigate-to-page, invoke-trigger |
field-group (form) | create-record, update-record, invoke-trigger |
actions (action bar) | invoke-trigger, navigate-to-page, start-orchestration, enqueue-job |
Activation modes¶
The activation mode controls how the user triggers the action:
| Mode | Behavior | Default For |
|---|---|---|
row-click | Triggered by clicking a table row | table, related-list |
button | Triggered by clicking a button | field-display, actions |
form-submit | Triggered by submitting a form | field-group |
Navigate to page¶
The navigate-to-page action redirects the user to another page in the same workspace. It is the primary mechanism for building multi-page navigation flows.
Basic navigation¶
{
"id": "action-view",
"type": "navigate-to-page",
"label": "View",
"targetRef": "order-detail",
"activation": "row-click"
}
The targetRef is the slug of the destination page.
Passing data via query parameters¶
To pass data from the current row or record to the destination page, enable useQueryParams and configure paramConfig:
{
"id": "action-view",
"type": "navigate-to-page",
"label": "View Order",
"targetRef": "order-detail",
"activation": "row-click",
"config": {
"useQueryParams": true
},
"paramConfig": {
"source": "row",
"mode": "selected",
"selectedFields": ["id"]
}
}
This produces a URL like: https://pages.centrali.io/my-workspace/order-detail?id=abc-123
Parameter configuration¶
The paramConfig object controls what data is passed:
| Field | Description |
|---|---|
source | Where the data comes from: row (table row), record (detail record), form (form fields), none |
mode | all (pass all fields) or selected (pass only specified fields) |
selectedFields | Array of field names to include (when mode is selected) |
Use selected mode
Prefer mode: "selected" with explicit selectedFields over mode: "all". This keeps URLs clean and avoids passing unnecessary data.
Renaming parameters with paramMapping¶
By default, selected fields are passed as query parameters using their original field names. Use paramMapping to rename fields in the URL — for example, passing a field called requestId as id in the query string.
{
"id": "action-view",
"type": "navigate-to-page",
"label": "View Request",
"targetRef": "request-detail",
"activation": "row-click",
"config": {
"useQueryParams": true,
"paramMapping": {
"requestId": "id",
"teamId": "group"
}
},
"paramConfig": {
"source": "row",
"mode": "selected",
"selectedFields": ["requestId", "teamId", "status"]
}
}
With a row containing { requestId: "req-123", teamId: "eng", status: "open" }, this produces:
Fields without a mapping entry (status in this example) use their original name.
paramMapping requires all three: action type navigate-to-page, useQueryParams: true, and paramConfig.mode: "selected".
In the console editor, the param mapping panel appears automatically when you enable "Pass fields as URL query params" and set the mode to "Selected Fields". Enter the desired URL parameter name for each field, or leave blank to use the original name.
Values are resolved from the clicked row — the runtime checks the top-level row data first, then falls back to nested row.data fields.
Invoke trigger¶
The invoke-trigger action calls an on-demand function trigger, allowing you to run server-side logic from a page interaction.
{
"id": "action-approve",
"type": "invoke-trigger",
"label": "Approve",
"targetRef": "TRIGGER_ID",
"activation": "button",
"confirmationRequired": true,
"paramConfig": {
"source": "record",
"mode": "selected",
"selectedFields": ["id", "amount"]
}
}
The targetRef is the trigger ID. The data specified by paramConfig is sent as the action payload.
Create and update record¶
Form blocks typically use create-record or update-record actions:
Create record¶
{
"id": "action-submit",
"type": "create-record",
"label": "Submit Order",
"targetRef": "COLLECTION_ID",
"activation": "form-submit",
"paramConfig": {
"source": "form",
"mode": "all"
},
"postSubmit": {
"behavior": "message",
"message": "Order created successfully!"
}
}
Update record¶
{
"id": "action-save",
"type": "update-record",
"label": "Save Changes",
"targetRef": "COLLECTION_ID",
"activation": "form-submit",
"paramConfig": {
"source": "form",
"mode": "all"
}
}
The targetRef for record actions is the collection ID.
Action feedback¶
All actions display toast notifications to confirm the result. Toasts appear in the bottom-right corner of the page.
- Success: shows the custom
postSubmitmessage if configured, otherwise "{action label} completed" or "Action completed" - Error: shows the error message from the backend
For async actions (invoke-trigger, start-orchestration, enqueue-job), the feedback depends on the execution mode:
- fire-and-forget (default) — a success toast appears immediately after the action is dispatched, without waiting for completion
- fire-and-poll — the UI polls the backend every 2 seconds (up to 60 seconds) until the action completes or fails, then shows the appropriate toast
Action status is tracked in Redis with a 10-minute TTL. The status endpoint is GET /runtime/v1/{ws}/actions/{actionId}/status.
Post-submit behavior¶
After an action completes, you can control what happens next with postSubmit. This applies to create-record, update-record, invoke-trigger, start-orchestration, and enqueue-job actions.
| Behavior | Description |
|---|---|
message | Show a success message to the user |
navigate | Redirect to another page |
Show a message¶
Navigate after submit¶
Start orchestration and enqueue job¶
These actions integrate with Centrali's automation and scheduling systems:
Start orchestration¶
{
"id": "action-provision",
"type": "start-orchestration",
"label": "Start Provisioning",
"targetRef": "ORCHESTRATION_ID",
"activation": "button",
"confirmationRequired": true
}
Enqueue job¶
{
"id": "action-export",
"type": "enqueue-job",
"label": "Export Report",
"targetRef": "JOB_DEFINITION_ID",
"activation": "button"
}
Execution modes¶
Actions that call server-side logic (invoke-trigger, start-orchestration, enqueue-job) support two execution modes:
| Mode | Behavior |
|---|---|
fire-and-forget | Action is dispatched and the UI immediately shows success |
fire-and-poll | Action is dispatched, the UI shows a loading state, and polls for completion |
{
"id": "action-process",
"type": "invoke-trigger",
"label": "Process",
"targetRef": "TRIGGER_ID",
"executionMode": "fire-and-poll"
}
With fire-and-poll, the runtime tracks the action status in Redis. The UI polls the status endpoint until the action completes or fails:
- Running: Action is in progress, UI shows a spinner
- Completed: Action finished successfully, UI shows the result
- Failed: Action encountered an error, UI shows the error message
When to use each mode
Use fire-and-forget for quick operations where the user does not need to wait for a result. Use fire-and-poll for longer-running operations where the user needs confirmation that the action completed.
Confirmation dialog¶
Set confirmationRequired: true on any action to show a confirmation dialog before executing:
{
"id": "action-delete",
"type": "invoke-trigger",
"label": "Delete",
"targetRef": "TRIGGER_ID",
"confirmationRequired": true,
"presentation": {
"display": "button",
"color": "destructive"
}
}
Action presentation¶
The presentation object controls how the action button is displayed:
| Field | Options | Description |
|---|---|---|
display | button, icon, icon-button | Button style |
icon | Any icon name | Icon to display |
color | primary, secondary, destructive, neutral | Button color theme |
Form field defaults¶
Form blocks can define hidden fields with derived default values. These are resolved server-side at submit time and cannot be tampered with by the client:
{
"blockType": "field-group",
"fields": [
{
"key": "title",
"label": "Title",
"type": "text",
"required": true
},
{
"key": "createdBy",
"label": "Created By",
"type": "hidden",
"defaultValue": { "source": "auth", "field": "userId" }
},
{
"key": "submittedAt",
"label": "Submitted At",
"type": "hidden",
"defaultValue": { "source": "system", "field": "now" }
}
]
}
Available derived default sources:
| Source | Field | Resolves to |
|---|---|---|
auth | userId | Authenticated user's ID |
auth | email | Authenticated user's email |
auth | name | Authenticated user's display name |
system | now | Current ISO 8601 timestamp |
system | uuid | Randomly generated UUID |
Auth defaults require authentication
If a form has hidden fields with auth defaults and the page is public, form submission will fail with an error. Set the page access policy to authenticated or role-gated when using auth-derived defaults.
Related documentation¶
- Pages Overview — Page types, sections, blocks, and access control
- Data Sources & Variable Binding — Dynamic filtering with variable bindings
- Triggers — Setting up on-demand triggers for
invoke-triggeractions - Automations — Orchestration workflows for
start-orchestrationactions