Triggers

A published workflow can be started seven ways from outside Studio. All seven run the same deployed version of the graph and are subject to the same concurrency ceiling; they differ in who authenticates, and in how the payload reaches {{ trigger.* }}.

Inside Studio there is also the Manual trigger, which starts a run from the Run button. Each trigger has a page in the Triggers group of the node reference with every setting, what a run receives, its limits and how it travels in a Package; this page covers what they have in common.

Every run also carries {{ run.trigger.type }} — api, webhook, form, schedule, manual, email, knowledge-document or app — so a graph reachable several ways can branch on which one actually fired. It is set by the platform and no payload field can change it.

Several triggers on one workflow

One workflow can have more than one trigger, for example a Webhook for your CRM, a Recurrence that runs every night, and an Email trigger for a shared inbox. Each trigger starts a run of the same graph.

• One of each kind. A workflow can hold at most one Webhook, Form, Recurrence, Email and App trigger. Studio refuses to add a second one of these, and says why; a graph that carries one anyway (sent through the API, say) fails to save with a message naming both nodes. The Webhook and Form triggers each get one URL per workflow, and the Recurrence, Email and App triggers each get one schedule per workflow, so a second node of the same kind would never fire. To run on several times of day, use one Recurrence trigger with a cron expression (for example 0 9,17 * * 1-5). Manual and Knowledge Base document triggers are not capped.
• A run starts from the trigger that fired. Only that trigger's branch runs. Every other trigger node, and every node reachable only from it, shows as skipped in the run trace. A node wired from two triggers runs whichever of them fired. The Webhook's declared fields are checked only when the Webhook fired, so a scheduled run of the same workflow is not rejected for a missing request body.
• trigger.* is the payload of the trigger that fired. A node shared by a Webhook and a Recurrence trigger sees {{ trigger.body.orderId }} on a webhook run and an empty payload on a scheduled one. Branch on {{ run.trigger.type }} with an If / Else node when the two need different handling. {{ run.trigger.id }} is the id of the trigger node that fired, and the run's history in the Activity tab shows the same node as complete.
• Runs are independent. Two triggers firing at the same moment start two runs. Each counts against the concurrency ceiling on its own.
• Publishing arms all of them; unpublishing disarms all of them. That includes Package installs and uninstalls.
• The API. POST /workflows/{workflowId}/run starts from the Webhook trigger if the graph has one, otherwise from the Manual trigger, otherwise from the first trigger.
• Testing in Studio. When the graph has two or more triggers, the Run dialog asks which one to Start from and prompts for that trigger's fields only. Retrying a failed run starts from the same trigger the failed run started from.

API

The path most integrations want. POST /api/v1/workflows/{workflowId}/run blocks for up to 30 seconds and returns the result; POST /api/v1/workflows/{workflowId}/run-async returns a run id immediately. Both are covered in full in the API reference.

The graph does not need a Manual trigger node for this to work — publishing is the only prerequisite.

Manual

Runs from Studio's Run button, or Run on the node. A Manual run sends its input flat. See Manual trigger.

Webhook

Lets a third-party system that has no Elizon API key start a run by POSTing to a URL unique to your deployment, authenticated by an HMAC signature or an API key. The payload arrives under body. See Webhook trigger for signing, the status codes and the declared fields.

Form

Lets a person start a run by filling in a hosted form, open to anyone, behind Basic auth, or limited to members of your organization. Submitted values arrive under body. See Form trigger for the field types, file uploads and the status codes.

Recurrence

Elizon starts the workflow on a schedule: every N minutes, hours, days or weeks, or on a cron expression in a time zone. A scheduled run carries an empty payload. See Recurrence trigger.

Email (IMAP)

Elizon watches a mailbox folder and starts one run per new email, with the message parsed and its attachments stored as files. Email content is untrusted input: read the warning on the Email trigger page before connecting an Agent to it.

Knowledge Base document

Elizon starts one run each time a document finishes indexing in a knowledge base you choose, so the run can already search it. See Knowledge Base document trigger.

App triggers

Elizon polls a connected account — a Google Drive folder, a calendar, a sheet — and starts one run per new item. See App triggers and each app's page under Apps.

Where to go next

• Workflows API reference — request and response shapes.
• Publishing — the prerequisite for all seven triggers.
• Human Review — the gate to put between an email-reading Agent and anything irreversible.