Triggers
What starts a run, and how to have a button as well as a clock.
A trigger is the leftmost thing on the canvas. It says when a run happens and nothing else: what the run then does is the steps beside it.
An automation has one thing that starts it. The exception is the dashboard button, which can sit alongside any of the others, because it is permission for a page to start a run rather than a second clock.
The triggers
| Trigger | It runs |
|---|---|
| I press Run | Only when you ask, from the automation's own page |
| On a schedule | Every so many minutes, hours or days |
| When data refreshes | As soon as a dataset you pick finishes updating |
| From the app | When somebody presses a button or adds a file on a dashboard |
| On a webhook | When something posts to a URL Flitch gives you |
| After another one | Once an automation you pick has ended successfully |
| When one fails | When an automation you pick errors |
A trigger pointed at nothing listens for nothing. Pick the dataset, or the automation to follow, or it will look finished on the canvas and never run.
On a schedule
Choose the interval, and optionally the time to count from, so "daily from 9am" keeps landing on 9am rather than drifting to whenever the last run happened to start.
The next run is stamped when a run is dispatched, not when it finishes, so an automation that takes longer than its own interval cannot start again while it is still going.
A schedule is held to the same floor as a data refresh on your plan. Ask for something faster than your plan allows and it is slowed on save, with a note saying so. See Intervals.
When data refreshes
This is the right trigger for work that depends on fresh data, and it is better than a clock of its own for exactly one reason: timing. An automation on its own schedule runs at 9:05 against data refreshed at 9:00, or at 8:59 against yesterday's. This one runs the moment that dataset finishes updating, every time.
Pick the dataset it should watch. It fires for that dataset only.
On a webhook
The automation is given an address of its own. Anything that can post to a URL can start it: a warehouse system when a shipment leaves, a form when somebody submits it.
You can set a secret header, which the far end must send for the call to be accepted. It is stored and never shown again, and it is stripped from any copy of the automation, so duplicating one never hands its credential to whoever pressed duplicate.
A schedule and a button
"Every Monday, and also when I press this" is one automation with two triggers: the schedule, and From the app. The scheduler reads the first; a dashboard reads the second.
Add From the app whenever a page is going to carry a run control. Without it the page can still show what the automation produced, but pressing a button would be refused: that trigger is the whole of the opt-in for a pipeline being reachable from a dashboard, including a published one. See From a dashboard.
Following another automation
After another one and When one fails chain automations together without either knowing about the other's schedule. The common pair is one automation doing the work and a second one, on When one fails, emailing you the reason.
Both fire from the automation you pick, so a chain is built by pointing each link at the one before it.