Triggers

Product documentation

Triggers are the entry nodes that start workflow Runs. Every workflow needs at least one — the editor’s Run button stays disabled until you add a trigger node. A workflow can have several triggers, and each one starts runs independently. Trigger registrations sync every time you save the workflow.

Enabling and disabling

The Enabled toggle — in the editor toolbar and on each card in the Workflows list — arms and disarms all of a workflow’s triggers at once. While a workflow is disabled, schedules stop firing, webhook requests are rejected, and record events pass it by. You can still click Run in the editor: manual editor runs work on disabled workflows, so you can build and test before switching a workflow on.

Archiving a workflow also disarms its triggers; restoring it re-arms them. Message and Call bindings have their own per-binding Enabled setting (see below) on top of the workflow toggle.

The Enabled toggle also shows which version triggers will run — the active release if you set one, otherwise the saved workflow. See Visual Workflows for drafts, saved versions, and releases.

Manual Start

Starts the workflow when you click Run in the editor. Best for testing and ad-hoc executions. Outputs include any input data passed to the run, the trigger time, and who started it. Turn on Include full context in the node settings to also emit a context object with timestamp, user, workspace, and workflow details.

Schedule

Starts the workflow on a recurring cron schedule.

  • Cron Expression — standard 5-field cron: minute, hour, day of month, month, day of week. Examples: 0 9 * * * (daily at 9:00), 0 0 1 * * (1st of each month at midnight), */30 * * * * (every 30 minutes).
  • Timezone — IANA timezone the schedule is evaluated in. Defaults to UTC.
  • Description — optional human-readable note, echoed on the node’s schedule output.

Schedules are checked once per minute, and a trigger never fires twice within the same minute. An invalid cron expression is rejected when you save the workflow, so it can’t sit broken in the schedule.

Incoming Webhook

Starts the workflow when an HTTP request hits the trigger’s endpoint. Each webhook trigger gets its own URL containing an unguessable token:

POST https://<your-workspace-host>/webhook/<token>

Requests to /api/hooks/<token> reach the same endpoint. Save the workflow with the trigger enabled before sending requests — calls to a disabled trigger return 403, and unknown tokens return 404.

A successful delivery responds with 202 and a JSON body containing the run id and a status of enqueued, or deduped when the delivery was recognized as a repeat.

Request data

The node echoes the request to downstream nodes: method, path, query parameters, parsed body, and headers. Sensitive headers (authorization, cookies, API keys, signatures) are always redacted. Include Headers is on by default; Include Raw Body is off by default — turn it on if a downstream node needs the unparsed bytes.

Signature verification

Set HMAC Secret to require a valid signature on every request:

  • Signature Header — where the signature arrives. Defaults to X-Signature; prefixes like sha256= are accepted.
  • HMAC Algorithm — sha1, sha256 (default), or sha512, computed over the raw request body.
  • Timestamp Header — optional. Set it to enforce freshness: the header must carry an ISO 8601 timestamp within Timestamp Tolerance (default 300 seconds). Leave blank for providers that don’t send one.

Requests with a missing or wrong signature return 403. See Security for how stored secrets are protected.

Deduplication and event identity

Redelivered events don’t start duplicate runs. The delivery key comes from, in order: the configured Delivery Key Header, a known provider delivery-id header (GitHub, GitLab, Atlassian, and similar), or a hash of the request body — so byte-identical redeliveries dedupe automatically.

Provider Slug and Event Type Header shape the node’s event and event_type outputs (for example webhook.github.push), which is useful when one endpoint receives several event types.

Handshakes and limits

  • GET and HEAD requests to the webhook URL return 200, so providers that validate URLs before delivering events can complete their handshake.
  • Request bodies are limited to 256 KB (413 beyond that).
  • Deliveries are rate limited to 100 requests per minute per workspace (429 when exceeded).

Record Created and Record Updated

Start the workflow when a record changes. Pick the Record Type — Task, Project, or a Custom Record type (see Record Types & Records) — then narrow with optional filters:

  • Tasks: Filter by Project and Filter by Task Type.
  • Custom records: Custom Record Type selects which type fires the trigger.
  • Record Updated only, for tasks: Filter by New Status fires only when the updated task’s status matches a status slug such as in-progress.

Record Created emits the full created record. Record Updated emits the record’s id, title, project, current and previous status, and the list of changed fields.

Entity Workflow

Runs the workflow on demand from a record’s page rather than automatically. Configure the Record Type — Task, Project, Team, Objective, or Custom Record — plus optional project, task type, or team filters that control where the workflow is offered.

Matching workflows appear in the Workflows panel of the record’s sidebar with a Run button. Clicking Run starts the workflow with that record and the person who clicked as inputs. Only enabled workflows are offered.

Message and Call

Entry nodes for conversational agents. Instead of node settings, both are configured through bindings: a binding connects an agent identity to a source — a chat channel, a DM, or a bot Connection — and authorizes it to act there. Open the node’s settings sidebar and click Add binding, then pick the Agent and Source. Each binding has its own Enabled setting. Manage agent identities under Settings → Agents.

  • Message — starts a run when the bound agent is mentioned in the source. The optional Mention token overrides the trigger word; it defaults to the agent’s handle. The node emits the message text, the full message, the author, attachments, and a dispatch envelope to wire into a Reply node.
  • Call — starts a run when a call begins in the bound channel or DM. The node streams the participant’s live audio into the flow (wire it into Speech to Text) and emits the call’s metadata.

Gmail: New Email

A polling trigger: checks a Gmail inbox on an interval (Poll Interval, default every 60 seconds) and starts the workflow for messages matching your filters. Requires a Google Connection.