Triggers/Workflow Initiation
Triggers / Workflow Initiation
The trigger is the starting point of a workflow — the step that decides how a request gets initiated. On the canvas, the trigger is the workflow's first node, shown as the Start Node.
A workflow can be initiated in two ways:
- Manually — a user starts it from the Virtual Assistant (conversation) or a web-view.
- Via API — an external system starts it with an API call.
You configure this behaviour on the trigger (Start Node). The options below control initiation, what's returned to an API caller, and how often a workflow can be run.
Initiation & error handling
| Configuration | What it does |
|---|---|
| Fail workflow initiation | If any node in the synchronous block between the Start Node and the initiator input fails, the whole initiation is treated as failed (rather than continuing). |
| Error message display | Controls what the user sees when initiation fails: a generic message, or the specific error message configured on the Action/Function node that failed. |
| Trigger actions when request is withdrawn | When enabled, a separate flow runs each time an in-progress request is withdrawn (for example, to reverse a step or notify someone). |
API / webhook initiation
| Configuration | What it does |
|---|---|
| Enable API-triggered initiation (allow execution via webhook) | Allows the workflow to be started by an API call, not just manually. On by default. See Initiate workflow via API. |
| Enable external webhook initiation | Allows the workflow to be started from an external webhook source (a third-party system posting to the trigger), separate from the standard API initiation. Off by default. |
Trigger Sync (run logic at initiation)
You can have the workflow run a Trigger Sync — the synchronous block on the trigger path executes at initiation, before the request proceeds — to fetch or compute data up front (for example, look up the requester's details, or validate against an integration).
- Execute Trigger Sync — runs that synchronous block synchronously during initiation.
- Merge Trigger Sync response — includes the Trigger Sync block's output in the response returned to the API caller.
Trigger Sync is also how you pre-fill the initiator form with live data. See Sync Block Node.
API response (JSON template) and purge
When a workflow is initiated via API, the trigger returns a JSON response to the caller, defined by a response template (defaults to {}). The template can include Data Center values so the response carries back the data you choose.
- Purge stored JSON response — when enabled, the stored response from external trigger submissions has all its values replaced with
** PURGED **while keeping the structure. Use this to avoid retaining sensitive values that were submitted through an external trigger.
Restricting execution (frequency & concurrency)
You can limit how often a user can run a workflow. When a user exceeds a limit — whether they initiate manually or via API — the request is blocked and an error is returned.
There are two restriction types:
- Frequency — caps the number of requests within a time period: a maximum count per day, week, month, quarter, year, or lifetime (for example, "max 3 requests per day per user").
- Concurrency — caps the number of in-progress requests a user can have at once (for example, a user can only have one request of this workflow running at a time).
You set the limit, the time period (for frequency), and the error message shown when the limit is hit.
The Start NodeThe trigger node is displayed as the Start Node. Existing workflows that still used older default names (like "Trigger" or "Manual Trigger") are normalized to "Start Node", unless a builder had renamed the node — custom names are preserved.
Updated 11 days ago