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.payload}}              → 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

Every save records a new plan 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 productionclears 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.

Two metadata fields, _webhookMethod and _webhookTimestamp, are added to the payload. The sync query parameter is removed from it.

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

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 after every cycle of the parent that had no failed step.
• For a single-shot parent run, it fires when that run ends COMPLETED.

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}} or directly with {{trigger:on_done.output.<parent field>}}. 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.

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 Resetsevery month, every week, or never. It counts agent spend on every run except a test fire from the builder. Once the period's spend reaches it, no new epoch opens until the allowance starts again. See Plans & billing.

Troubleshooting

Related pages