Triggers
Entry nodes start a run: manual invoke, inbound webhook, or a schedule. They declare the initial payload shape the rest of the graph consumes.
Overview
Every workflow has at least one trigger (entry) node. It defines how a run starts andwhat fields arrive on the first hop. Downstream steps read those fields as {{input.*}} and always as {{trigger_inputs.*}} on later hops.
Steps in this family
Invoke (manual)
Starts when a person or integration sends a payload through the product's run action. You declare invoke fields and optional globals on the Inputtab; those keys become the first step's output.
Webhook
Starts when an HTTP caller hits your workflow's webhook URL. The body, headers, or query parts you map become the invoke-shaped payload: design fields so your API consumers stay stable across versions.
Schedule
Starts on a cron-style timetable. Scheduled runs often carry a minimal synthetic payload or timestamps; combine with expression variables such as now when you need fresh filenames or window labels.
GitHub
Starts when GitHub delivers a signed webhook for a connected repository (issues, pull requests, comments, or push). Configure repository and events on the Event tab; map payload fields on Input.
Vercel
Starts when Vercel posts a deployment event for a connected team (optionally scoped to one project). Use this for deploy-failed alerts, post-deploy checks, or promotion workflows.
Configuration
Triggers use General (label, description) and the combined Input tab for payload schema, globals, and trigger-specific wiring, not the Execution tab used by AI or code steps.
Data flow
If you declare no custom output rows on the trigger, the runner typically forwards the whole invoke object to the next step. Once you add mapped rows, those mappings define exactly which keys appear on the output object.