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.
Where these settings are
All of the settings below live in one place: open your workflow in the Workflow Canvas, click the Start Node (the first node in the flow), and configure them in its settings panel.
A few options only appear once a parent toggle is switched on — for example, the API-response and Trigger Sync settings appear only after you enable API-triggered initiation. Those dependencies are noted below.
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
Turn on Enable API-triggered initiation of Workflow to let the workflow be started by a REST API call, so it can be integrated with third-party services — not just started manually. See Initiate workflow via API.
Enabling it reveals these additional settings:
| Configuration | What it does |
|---|---|
| JSON response template | Defines the JSON returned to the API caller (defaults to {}). Include Data Center values to pass data back in the response. |
| Consider execution of sync block between workflow trigger & initiator input | Runs the synchronous block between the Start Node and the initiator input during initiation (a "Trigger Sync"), so data can be fetched or computed up front. On by default. |
| Allow filling of form data via sync block between initiator input/workflow trigger | Lets that sync block's action nodes and field mapping populate the form data. On by default. If the same field is supplied by both the API request body and the sync block, the request body takes precedence. |
| Allow execution of workflow externally via web-hook | Additionally allows the workflow to be triggered externally via a webhook. Off by default. |
Trigger Sync is also how you pre-fill the initiator form with live data. See Sync Block Node.
Purging the stored JSON responseFor requests initiated through an external trigger, the stored JSON response can be purged — every value is replaced with
** PURGED **while the structure is preserved. Use this when the submitted payload contains data you don't want retained.
Restricting execution (frequency & concurrency)
Turn on Limit execution of workflows basis restrictions to cap how often a user can start this workflow. When a user exceeds the limit — initiating manually or via API — the request is blocked and an error message is returned.
Then choose the restriction type under Workflow Initiation Restrictions:
- Frequency-based (Time Period Limits) — caps the number of runs in a period. Set Maximum runs, per Time Period, and the Time unit (day, week, month, quarter, year, or lifetime). For example, max 3 runs per 1 day.
- Concurrency-based (Active Workflows) — caps how many requests a user can have running at once, via Maximum concurrent in-progress workflows per user. For example, a user may only have one active request for this workflow at a time.
You also set the error message shown when a limit is hit.
Updated 7 days ago