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.
A workflow 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 workflow'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 a workflow you pick has ended successfully |
| When one fails | When a workflow you pick errors |
A trigger pointed at nothing listens for nothing. Pick the dataset, or the workflow 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 a workflow 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. A workflow 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 workflow 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 workflow, 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 workflow 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 workflow produced, but pressing a button would be refused: that trigger is the whole of the opt-in for a workflow being reachable from a dashboard, including a published one. See From a dashboard.
Following another workflow
After another one and When one fails chain workflows together without either knowing about the other's schedule. The common pair is one workflow doing the work and a second one, on When one fails, emailing you the reason.
Both fire from the workflow you pick, so a chain is built by pointing each link at the one before it.