Triggers

Triggers are the entry nodes that start workflow Runs. Every workflow needs at least one — the editor's Test button stays disabled until you add an executable trigger node. A workflow can have several triggers, and each one starts runs independently.

Running and Paused

Production has two independent controls:

  • Publish freezes the exact Draft as an immutable Release and makes it Current. Production never falls back to a Draft or another mutable workflow copy.
  • Start lets the Current Release accept new production entries; Pause rejects new entries without changing Current. A workflow's first Publish remains Paused until you explicitly Start it.

While a workflow is Paused, schedules do not fire, webhook requests are rejected, and record events pass it by. You can still click Test in the editor to run the current Draft. Pausing does not interrupt runs already in progress: every admitted run continues with the immutable Release and execution settings it captured at admission.

Publishing or restoring a Release updates the workflow's production trigger registrations. If no Current Release exists, every production entry is rejected rather than falling back to authoring state. Archiving makes the workflow unavailable for new production entries while preserving its Draft, Releases, and run history; restoring the workflow returns it to its prior Running or Paused state.

Disabling an individual trigger node removes it from the executable graph. It stays visible for later editing and remains in Release history, but does not register or start production runs. Disabled action nodes and disabled edges are likewise skipped during execution.

Message and Call bindings also have their own per-binding availability control (see below). A binding can admit work only when it is available, its trigger node is executable in the Current Release, and the workflow is Running.

Manual Start

Starts the workflow on demand. Click Test in the editor to run the current Draft as a debug run. For production, Publish a Release, Start the workflow, and use Run now from the Workflows list. 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 can remain in your autosaved Draft, but Publish rejects it so a broken schedule cannot become Current.

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. Publish a Release containing the executable trigger and Start the workflow before sending requests. Requests are rejected while the workflow is Paused or the trigger node is disabled; 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, and parsed body. Include Headers and Include Raw Body are both off by default; turn them on only when a downstream node needs them. Sensitive headers (authorization, cookies, API keys, signatures) are always redacted when headers are included.

Signature verification

Select or create a tenant secret in HMAC Secret to require a valid signature on every request. The workflow stores only the secret reference; plaintext HMAC values are rejected:

  • 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), and the signature must cover timestamp + "." + raw body. 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. Signed requests deduplicate from the exact authenticated preimage, so changing an unsigned delivery header cannot replay the same signed event. For unsigned requests, 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.

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 Current Release with that record and the person who clicked as inputs. Only Running workflows whose Current Release contains an executable matching trigger 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 availability control. Manage agent identities under Resources → 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.