Triggers & actions
What starts it,what it does, how it decides.
Three questions, and every workflow on this platform is an answer to them. This page is the vocabulary: the ways a run can begin, the things a step can do, and the pieces that shape the path between the two.
Triggers
Four ways a run begins.
A schedule
Every ten minutes, every Monday at seven, the first working day of the month. Expressed in a timezone you choose, so the clocks going back is not an incident.
A webhook
Your shop, your CRM, your billing system, anything that can make an HTTP request. Signature verification is on by default and the payload is kept with the run.
An event from the world
A concert announced, a fixture scheduled, an earthquake, a flood warning, an air-quality band crossed, a provider outage. More than 175 sources, refreshed every ten to twenty minutes.
A poll, or a person
Watch an endpoint, a mailbox or a folder and start when something changes. Or start it by hand, from the console, because sometimes that is the honest answer.
One run per thing. A trigger that fires twice for the same underlying event — a webhook retried by the sender, a poll that sees the same row again — starts one run, not two. Deduplication is keyed on whatever identifies the thing, and you can set that key yourself when the sender's idea of an id is worse than yours.
Actions
Steps that do something.
An action changes something outside the run: it writes, sends, charges, books, fetches or files. Two kinds, and the difference is whether a model is involved.
Deterministic actions
Call an HTTP endpoint. Read and write your own systems. Reshape a payload. Look something up in reference data. Send an e-mail, an SMS, a push notification or a printed letter. Offer a booking slot. Take a payment. Mint a short link. Fetch an image with its licence attached. Write a row, a file, a record.
Same input, same output. They cost nothing to run, which is why the honest advice is to use them for everything that does not genuinely need judgment.
AI actions
Classify this message. Draft that reply. Summarise a thread into three bullet points. Extract fields from an unstructured document. Choose between options given a rule you wrote in prose. Translate, keeping the tone.
Every AI step declares the shape of what it returns, and the return is validated against that shape before the run continues. If a model produces something malformed, the step fails cleanly instead of poisoning the next twelve steps.
Something happens.
Then the right thing happens next.
Flow steps.
They only think about the run.
Conditions branch on a value. Both paths are defined, always — a condition with an undefined else-branch is the commonest way an automation quietly loses records, so it is not possible to leave one dangling here.
Waits hold a run until a moment or an event. A wait is a wake_at written on the run itself, not a row sitting in a queue, which is why a workflow can hold ten thousand people for three weeks without any of it costing anything or anybody noticing.
Quiet hours stop outbound messages landing at three in the morning. A run that reaches a send step inside the quiet window waits for the window to close. Severity can override it, deliberately, for the alerts that are supposed to wake people.
Splits send a share of runs down path A and the rest down path B, so you can compare two subject lines, two waits or two orderings against each other on live traffic.
Goals mark the thing the workflow was for. When a run reaches its goal it stops there, whatever remained downstream — the customer who bought does not get the third reminder to buy.
- ⚡TriggerBasket idle for 40 minutes. Deduplicated on basket id.
- ?ConditionBasket over 150 zł? Yes — take the longer path.
- ⏸WaitA
wake_aton the run. No queue row, no cost. - ASplit50/50 on the subject line. This run took variant A.
- ✉SendE-mail with a short link, redirects counted per recipient.
- ★GoalOrder placed. Run stops here; the second reminder is never sent.
Steps that called a model: 1Steps that cost nothing: 5
Errors are part of the flow,
not an exception to it.
A step that fails has somewhere to go. Retry with a backoff, and a limit on how many times. Take an alternative path. Stop the run and file it where a person will see it. Carry on regardless, because that particular step was optional and you would rather have most of the outcome than none of it.
The default for a step that talks to somebody else's system is to retry a few times and then stop — because a system that is down at 09:14 is usually up at 09:19, and because a run that has stopped is easier to reason about than a run that has half-happened.
What you cannot do: a step cannot loop back to an earlier step. A workflow is a directed path, not a program with a jump instruction. If your job genuinely needs a loop, iterate over a list within a single step, or start a run per item — both are supported, and both are easier to read afterwards than a cycle would be.