Triggers
A trigger is the entry point of an automation—the thing that decides a run should start. Every automation begins with exactly one trigger, and it is the one node you cannot delete or leave out: an automation without a trigger has no way to begin. Changing how an automation starts means replacing its trigger with a different one, not adding a second.
When you add the first node and select Trigger, the panel groups what is available into General Triggers—the ones that ship with the product—and Integration Triggers, which fire on events in an external system and need a connection to that system.
What can start a run
Whatever the trigger, one of five things sets a run going:
| Kind | A run starts when… |
|---|---|
| A content event | Something happens to a record—in this workspace, or in a connected CMS—it is published, revised, moved through a workflow, archived, and so on. |
| A schedule | A recurring schedule comes due. Schedules are checked about once a minute, so one set finer than that may skip occurrences. |
| A manual run | You start it yourself, from the editor's run button or from a content edit page where the automation has been registered. |
| An inbound webhook | An external system sends a request to a URL that belongs to the trigger. Integration triggers work this way too—the connected system delivers its events over a webhook the trigger owns. |
| Another automation | A different automation finishes, or calls this one as a step. |
A trigger that fires on its own—a content event, a schedule, an inbound webhook—only does so once the automation is turned on. A trigger you start by hand runs whether the automation is on or not, which is what makes it safe to build and rehearse an automation before enabling it.
Starting a run by hand never disturbs the trigger's own schedule or subscription: a schedule still fires at its usual time afterwards, and run history tells the two apart—a run you started carries your name, a scheduled one carries its schedule.
What the trigger contributes to the run
A trigger is not only a switch. It also supplies the run's first piece of data, and that matters more than it sounds.
Whatever the trigger captured—the content that changed, the body of the webhook that arrived, the values you typed into a manual run's form—becomes the trigger's output. That output is the first entry in the run's vocabulary: the set of values later steps can reach for through the variable picker. Every step after the trigger can read it, so the trigger is where most flows get the thing they are actually about. Anything a trigger adds of its own—a schedule's tick, a webhook's query string—sits under a _trigger entry beside the event's fields, never among them, so a name the trigger invents can never replace one the event carried.
Different triggers contribute different shapes. A content event carries the content and what happened to it. A webhook carries whatever the sender posted. A manual or on-demand trigger contributes only what you asked it to: define a payload on the trigger and the run starts with those fields filled in; define none and the trigger produces no output at all, and the flow works entirely from what its own steps fetch.
Narrowing what a trigger responds to
A trigger usually subscribes more coarsely than you want. A content trigger can watch every asset on a CMS; a repository trigger hears about every event in the repository. Two mechanisms narrow that down.
Filters are part of the trigger's own configuration and vary by kind—limiting a content trigger to certain content types, limiting an issue trigger to a query, limiting a repository event to certain actions. They tell the connected system, or the trigger itself, which events are interesting in the first place.
Fire Condition is the general-purpose gate, available on the triggers whose events arrive from a system they subscribed to—the Content trigger and the GitHub and Jira triggers. (The built-in Webhook trigger, which you point an arbitrary sender at, has no fire condition.) It is a boolean expression—built the same way as an Expression condition—evaluated against the trigger's own output the moment an event arrives, before any run exists. If it evaluates false, no run is created and nothing is counted against your usage. Leave it unset and the trigger runs on every event it receives.
That "before any run exists" is the whole point. You could put a condition immediately after the trigger and end the run there instead, but that buys and records an execution just to discover the event did not apply. A fire condition rejects it for free.
Limiting concurrent runs
A trigger can also cap how many runs it has going at once, on its Advanced tab, under Concurrency. Nothing here takes effect until you choose an On Collision policy—leave it unset and every event starts a run, whatever the other fields say.
| Field | Description |
|---|---|
| Max Concurrent Runs | How many runs may be in flight at once before the collision policy applies. Defaults to 1 once a policy is chosen. |
| Concurrency Key | What counts as a collision. Leave it empty and the whole automation is a singleton—one run at a time, however many triggers feed it. Add a row and insert a reference through the variable picker—a payload field, say—to limit per entity instead: runs for different values proceed together, runs for the same value do not. Add more than one row and they are joined in order, so an entity plus a locale is two rows. |
| On Collision | What happens to an event that arrives while the cap is already met: Reject New drops it, Cancel Running stops the oldest run and starts this one, or Queue holds it until a slot frees. Choosing one of these is what turns concurrency limiting on for this trigger. |
| Max Queued Runs | With Queue, how many runs may wait on the same key before further events are refused outright. Defaults to 50. |
| Max Queue Wait (hours) | With Queue, how long a queued run waits for a slot before it is failed rather than left waiting. Fractions are allowed. Defaults to 24. |
The built-in triggers
For each trigger that ships with the product—what it fires on and every field it takes—see Triggers in the built-in node catalog.
Triggers from integrations
Connected systems add triggers of their own, each firing on that system's events. Depending on how the connection authenticates, the webhook behind such a trigger is either registered for you automatically or set up once by an administrator; the node shows which state it is in. See Integrations for what each system can trigger on.
An automation can start itself. If a trigger listens for the same kind of event that one of the automation's own actions causes—a content trigger on publish, in an automation that publishes content—the run can retrigger the automation, and nothing stops that loop for you. Guard against it with a condition that limits when the matching action runs, or a fire condition that ignores the automation's own changes.