The pieces
How they connect
Everything that reacts runs in the background, so the request that caused the event returns straight away, and a slow or failing reaction never slows your app.Where it is in Studio
A typical feature, end to end
“Email a receipt when an order is paid.”- Your app marks the order paid with a normal database update. The
orderstable emitsorders.updated. - An event subscription on
orders.updated, only when$event.payload.record.statusequalspaid, runs thesend-receiptflow. - The flow loads the customer with Get record and sends the
receipttemplate with Send email. - The email is queued, sent through your provider, retried if the provider fails, and logged in Mail activity.
- If anything fails, you see it under Activity, fix it, and retry or replay.
What your app does
Your app doesn’t configure any of this. It causes events by writing data, and it can call flows and routes directly when it wants an answer:Choosing the right piece
Reliability in one paragraph
Events are delivered at least once, reactions run independently and not in a fixed order, flows get one attempt unless you add a Retry block, emails get three, and webhooks get up to ten over days. Every failure is visible and can be retried or replayed. Design reactions to be safe to run twice. See Reliability and failures.Limits
Plans include a number of flow runs per month, scheduled tasks, inbound webhooks, outbound webhooks and emails per month. See Plans and limits.Events
Subscribe to what happens.
Flow editor
Build the steps.
Schedules
Run by the clock.
Webhooks
Talk to other systems.
Background jobs
Retry and replay.
Reliability
Design for failure.