Triggers

A run starts from one Trigger node. This page covers how each kind of start works once a workflow is live. The node’s own fields are on the Trigger page.

Start	What starts it	Runs	Run history shows
Run draft	A member, from the builder’s Test tab	The draft	The member’s name
API	Your code, with an organization key	The live version, or the draft	API
Schedule	A Schedule trigger’s next date and time	The live version	Schedule
App event	Something that happened in a connected app	The live version	App event and the trigger’s title

Only the draft runs by hand. A published version starts on its own from Schedule and App event triggers, and from a Manual trigger only through the API. Schedule and app event triggers listen only while the workflow has a published version and isn’t paused. See Versions and publishing and, for the API, Starting runs.

Several triggers

A workflow can have any number of triggers. Each run starts from exactly one. The others are skipped, and so is every step only they lead to. A step that two triggers share runs once.

For Run draft, pick the trigger in the Test tab. Through the API, name it with triggerNodeId. A workflow with a single trigger uses it without being told.

To switch off one trigger and keep the rest, set its Status to Disabled and publish.

Schedules

Each due Schedule trigger starts one run. The builder header and the run history show the next scheduled run. Times are in the time zone of the browser that published the version.

When your plan’s monthly runs are used up, a scheduled time is skipped and the schedule carries on with the next one.

App events

An App event trigger listens on one connection for one kind of event, with its filter. Apps are connected through Super Connect, which keeps a subscription for each connection, event and filter, and delivers matching events to Super Flows.

Publishing subscribes. If the app refuses, such as GitHub asking for admin access to a repository, the publish fails with the app’s message and nothing is saved.
Triggers share subscriptions. Triggers with the same connection, event and filter use one subscription.
Your plan caps active subscriptions: 2 on Free, 25 on Pro. A subscription is active while a live trigger uses it, and a shared one counts once. A publish or resume past the cap is refused before anything changes. The Billing page shows the count.
Filters are matched by the app. Slack and GitHub fields match exactly, Gmail fields match part of the text, ignoring case. For anything a filter can’t say, put a Conditional right after the trigger.
Some apps are polled. Gmail and Google Sheets are checked every 10 minutes, so an event can take that long to arrive.
A payload over 100 KB doesn’t start a run. Its event shows an error.

Slack

Slack is connected as a bot. The bot receives messages only from channels it is a member of, and posts only there. When a trigger’s filter names a channel the bot isn’t in, the builder warns “Invite the bot to #channel”. The bot’s own posts never fire a trigger.

Trigger health

Once published, each App event trigger shows on the canvas whether it is listening. A trigger stops when its subscription fails or its connection breaks or is disconnected. Select it to read why. An owner or admin presses Reconnect there, or Reauthorize on the Apps page, and its events resume. The Dashboard lists stopped triggers under Triggers stopped.

The app events list

The App events list, in the builder’s Runs tab and on the run history page, shows every event that reached the workflow’s triggers in the last 30 days, with what each trigger did:

Outcome	What it means
started	A run started. Open run goes to it.
limit reached	Your plan’s monthly runs were used up.
error	Starting the run failed. It is retried.
dead	Starting the run still failed after the last retry.
no listener	The trigger was no longer live when the event was replayed.

Replay on an error or dead event queues it again for that trigger, on the live version. An event that already started a run never starts a second one.

Pause and resume

Pause, in the builder header or under More on a phone, turns off the workflow’s schedule and app event triggers. The live version stays as it is, and Run draft and API runs still work. Nothing that happens while the workflow is paused is replayed later.

Resume turns the triggers on from that moment. Publishing while paused saves the new version and keeps the triggers off until you resume.