Triggers

The eight trigger types

A workflow can carry several triggers. Each one starts its own graph and keeps its own history of fires. Every trigger output is available downstream as {{trigger:<label>.output.<field>}}, where <label> is the normalized trigger label. A trigger node has no inputs: it is the entry point of the graph.

Reference any of them by the trigger's label:

{{trigger:webhook.output.order_id}}             → one field of the JSON body a webhook received
{{trigger:contact_form.output.email}}          → one field of a form submission
{{trigger:new_orders.output.row.status}}       → a column from the changed table row
{{trigger:on_failure.output.errorMessage}}     → why the upstream workflow failed

When an agent adds a trigger through the builder, the accepted type values are manual, chat, webhook, schedule, table, datasource, workflow, form, and error. table is an alias of datasource. Trigger labels must be unique within a workflow, and a trigger label cannot collide with another node's label after normalization.

Epochs: one run, many fires

Every trigger type is reusable. A fire does not start a new run: it opens a new epoch on the workflow's live run, which then rests in WAITING_TRIGGER until the next fire. Each epoch keeps its own results, so you can browse every fire of a schedule or every call of a webhook on the same run. Epochs are numbered per trigger. See Runs & execution for how to read them.

Which version a trigger fires

Each save that changes what the workflow does records a new plan version (moving its steps around does not, and the changes Orbi makes in one conversation share one version). Pinning a version, labelled Set as production in the version history, tells LiveContext which version the outside world talks to. There is no automatic pin.

Pin a version

1. 1
   Open the version history

   Open the workflow in the builder and open its version history.
2. 2
   Choose Set as production

   Pick the version and choose Set as production. If you have unsaved changes, Save & set as production saves them as a new version first.
3. 3
   Check the triggers

   The Webhook, Scheduler, Tables, Chat, and Form triggers are re-synced to the pinned plan straight away; a Workflows trigger reads the pinned version each time it fires. Open Public access or the Agenda to see them armed.

You can pin a version that has never run. If no run exists at that version, pinning creates the production run itself. Nothing executes and no credits are used; the run simply waits for its first fire. A plan with no trigger is pinned without a run.

Remove from production clears the pin and suspends the workflow's production triggers rather than deleting them. Pinning again arms them again. Moving production to another version switches every future execution to it; a chat conversation in progress runs the new version from its very next message.

When the production run ends

If the production run ends as failed, cancelled, or timed out, LiveContext points production at the newest other live run of the pinned version (or, failing that, a completed one). It never creates a new run for you. When no such run exists, production triggers skip until you pin again (which provisions a run) or reactivate the run from the run panel.

Webhook

A webhook trigger listens on a URL of the form {base}/webhook/{token}. Accepted methods are GET, POST, PUT, PATCH, and DELETE; a webhook accepts exactly one, and the default is POST.

Authentication fails closed: a request that does not pass the configured check, or a webhook configured with an auth type the platform does not recognize, gets 401.

There is no payload, headers, query, or method field: read body fields directly under output. Request headers never reach the workflow, so to check a shared secret, use the webhook's Header Auth. The sync query parameter is never passed on.

When an agent builds a webhook trigger, the webhook endpoint is created at once, so the URL works before the workflow is even saved. Its token is kept across re-pins, so the URL does not change as you iterate. It only changes when you regenerate the token from Public access, where you can also read the call history. The full HTTP surface, including the Respond to Webhook node, is in REST API & webhooks.

Scheduler

In the inspector you set the schedule with Frequency (presets, or Custom cron expression… to type one in Cron expression) and, under Advanced options, Timezone and Max executions. In runs mode, Schedule status shows the last and next run, and Execute now fires the schedule once right away.

Outputs: triggered_at, execution_count (starts at 1, alias executionCount), next_execution (aliases nextExecution and nextScheduled), and triggered_by (the workflow owner's display name). A schedule is armed only while the workflow has a pinned version. To see upcoming fires, move one, or run one early, use the Agenda.

Manual

No parameters. Running the workflow from the editor fires it. The fire reuses the live run of the same version when one exists and opens a new epoch on it; a new run is created only for a new version or when no live run exists. Outputs: triggered_at and triggered_by (alias user), the display name of whoever ran it (an empty string if unknown). Extra data_inputs passed when an agent executes the workflow are added as top-level fields.

Chat

A chat trigger fires on incoming messages. With no filter it fires on every message.

Filter which messages fire the run

An optional chatMatch block decides which messages fire the trigger.

Options: caseSensitive (default false), trimPrefix (default true, for STARTS_WITH) and trimSuffix (default true, for ENDS_WITH). With trimming on, extracted_message drops the matched command token. REGEX matches a substring, not the whole string.

A chat trigger built by an agent creates its public chat endpoint at once. You manage the endpoint and its share links in Public access.

Form

The form builder offers 17 field types:

select, multiselect, radio, and checkboxGroup need an options list, either plain strings or {label, value} pairs.

Outputs: submission_id, submitted_at (alias submittedAt), form_data (every field in one object, alias formData), triggered_at, triggered_by, plus one output per field, named after the field's name. The hosted form page and its share links are managed in Public access.

Tables (row changes)

The Tables trigger fires on changes to one of your tables. One row-level event fires once.

Configuration: table_id (or datasource_id, required), event_types to choose which changes fire (row_created, row_updated, row_deleted; omit it for all three), and an optional filter ({column, operator, value}) so only matching rows fire.

Filter operators: = (or ==, eq), != (or neq), > (gt), >= (gte), < (lt), <= (lte), in, not_in, contains, starts_with, ends_with, is_null, and is_not_null. The last two take no value; every other operator needs one.

When an agent executes the workflow without a real row event (a batch scan), the trigger emits data (an array of {id, data} rows) and count instead. Put a Split over output.data to process every row. See Workflows.

Workflows (chaining)

Starts this workflow when a parent workflow finishes. The only setting is workflow_id, the parent's id (required).

• For a parent with a reusable trigger (the usual case), the chain fires once after every cycle of the parent that had no failed step, when that cycle ends: also a cycle that waited on an approval, an interface or a timer. A restart that ends the same cycle again does not fire it a second time, unless that cycle had failed or was stopped and the restart is what made it succeed.
• For a single-shot parent run, it fires when that run ends COMPLETED. Its result is keyed by step id (mcp:fetch_rows) rather than by step name.

It never fires on a failure. To react to one, use the Error trigger below.

Read the parent's outputs with {{trigger:on_done.output.result.fetch_rows}} or directly with {{trigger:on_done.output.fetch_rows}}. There is no parent_outputs field.

Error

Starts an error-handler workflow when a parent workflow has a step fail. The only setting is parent_workflow_id.

• For a parent with a reusable trigger, it fires on any cycle with a failed step, whatever the run's own status.
• For a single-shot parent run, it fires when that run ends FAILED (or with the older PARTIAL_SUCCESS status).

Limits and safeguards

Endpoint limits per plan

On the cloud, the number of webhooks, schedules, chat endpoints, and form endpoints you can hold depends on your plan. Each kind has its own quota, shown as a gauge on its tab in Public access. Creating one past the limit is refused.

Buying pay-as-you-go credits does not change your plan, so it does not change these limits.

Chains and error handlers

• A Workflows or Error trigger is skipped when the target workflow already has 5 runs executing at once.
• Chains and error handlers never fire across workspaces.

Credits and spending caps

When the workspace is out of credits, a fire is not silently dropped: the trigger node fails with the error code CREDIT_EXHAUSTED and every downstream node is skipped. The run stays reusable, so the next fire after a top-up works with no action from you. A webhook caller may receive 402.

A workflow or application can also carry a Cost budget (set in the Advanced section when you create or edit it), which Resets every month, every week, or never. It counts what agents spend, sub-agents and browser agents included, on every run except a test fire from the builder: runs opened from the Applications page count. Once the spend reaches it (this period's, or the total for a cap that never resets), no new epoch opens and no new agent starts until the allowance starts again or, for a cap that never resets, until you raise it. The spend of an agent is recorded when it finishes, so agents already running then (the other items of a split, for example) finish too, and the total can end above the cap by what they spend. A refused fire leaves the run exactly as it was, including an epoch still in progress. A webhook caller receives 402 with the status budget_reached, a form submitter, an application's user (through its share link or the public application API) or a chat visitor is told it is not available for now (without your figures), and a refused schedule tick does not count toward the schedule's maximum number of executions. See Plans & billing.

Troubleshooting

Related pages