Triggers and schedules

A workflow sits still until something starts it. Three things can:

• A schedule. "Every weekday at 9am, Europe/Berlin."
• An event in another system. A contact is created, a board item changes, a form is submitted.
• You. A run you start yourself from the console.

You describe the timing in plain words during the interview, and the interview sets it. A trigger it sets has one of four shapes: a schedule, an event trigger the assistant subscribes to on your behalf, a webhook URL it mints and hands you to paste into the other service yourself, or an email trigger watching a mailbox. The webhook URL is how a Framer form, a Typeform or a colleague's script reaches a workflow, because there is nothing there to subscribe to. If you would rather write a cron expression yourself, Settings has a form for that.

Publish arms it, Pause disarms it

Publish is what makes a trigger live. Its own tooltip in the workspace says what it does: accept the current SOP and publish it as the active version. Arming one kind of trigger disarms the others in the same act, so a workflow can never be running on two trigger paths at once. Switch a workflow from a schedule to an event and publish, and the schedule stops firing.

Pause is the other half. It disables the schedule, disables the event registration, and then tells the third-party service to remove the subscription it created. The local half always succeeds, so pause is never stuck waiting on somebody else's API. If the remote delete fails, the trigger is marked as failed and parked rather than retried. A delete that failed halfway looks exactly like one that failed before it did anything, and re-running it on every sweep is how a single bad trigger turns into a pile of stray subscriptions. Publishing again is what releases a parked trigger. A webhook URL you pasted yourself has no remote subscription to delete, so none of this applies to one.

Running it yourself is the exception to all of this. Whatever else is armed, and even after a pause, the on-demand path stays open. The Pause button says so: disarm the trigger and unpublish, manual runs keep working.

That makes pause the honest way to retire a workflow. Pull it when the signup period ends, and you know no stray signup can fire it again, while it stays there to test and to bring back.

Every trigger becomes the same event

A schedule firing, a webhook arriving and you clicking Run now all produce the same canonical trigger event, and all three go down one execution path. The run log still records which of them it was, but it records every run the same way, and a workflow that switches from a schedule to an event does not need to be rebuilt to make that work.

What lands in the queue depends on the workflow's stage. A learning workflow runs its triggers one at a time, in order, so you can watch the backlog drain. A codified workflow runs them in parallel.

The same event never runs twice

Every trigger carries an idempotency key, and the claim on that key is a unique database row. A provider that retries a delivery, a scheduler tick that examines the same due row twice, a restart in the middle of a fire: all of them land on a key that is already claimed and are dropped.

The key is built differently per source, and each one is chosen so that a retry agrees with itself:

• A scheduled occurrence keys on the schedule and the fire time, so the 09:00 occurrence is one occurrence however many times the poller sees it.
• A webhook delivery keys on the provider's own delivery id when the trigger declares where to find it. An authored trigger that declares none falls back to a hash of the request body, which counts as the same delivery for 15 minutes and covers every provider retry schedule we have looked at. A webhook URL has no such fallback: one request is one run, because a form submitted twice with the same answers is two submissions rather than a retry.
• A run you start yourself gets a fresh key each time, because clicking twice means you wanted two runs.

Where to go next