The rules your business already has, written down where the software can see them
Every company runs on a handful of sentences that live in somebody’s head or in a policy document: a big discount needs sign-off, a won deal tells finance, a lead from the website goes to whoever is on duty. A flow is one of those sentences, made real.
A standing rule, dry-run before it is switched on.
When a lead is created, give it to Sam, wait three days and post to a webhook, read back as a rule, tried against last month’s records, and switched on. Then one that runs every morning.
Say it once; read it back before it runs
You describe the whole automation in one sentence, not step by step. What comes back is the flow drawn out (the trigger, the conditions, every step) and a dry run against real records showing exactly what would have happened.
Nothing is enabled until you say so. A flow that turns out to be wrong on the third condition is a flow you find out about now, on a preview, rather than next Tuesday on two hundred records.
- Triggers: a record created, a record updated, a schedule, or an HTTP call
- Conditions on any column, including ones you defined
- Steps run as a chosen identity, so permissions still mean something
- Run history, with the reason a run did nothing
- A flow that keeps failing disables itself instead of retrying for ever
What a step can do
- Create a record
- In any table, with values taken from the record that triggered it or written literally.
- Update a record
- The trigger record, or a related one, with the same validation a person would face.
- Assign
- To a person, a team, or round-robin across whoever is on duty. Assignment rules are flows now: one mechanism, not two.
- Send mail
- From a template, through the workspace relay or through the sender’s own connected mailbox.
- Notify
- A person or a team, in the app, with a link back to the record that caused it.
- Call another system
- An HTTP request to a URL you configure, with the response available to later steps, and SSRF properly handled, so a flow cannot be pointed at your own internal network.
Triggered from outside, too
A flow can have an HTTP endpoint of its own. Your website form, your payment provider, a script on somebody’s laptop: anything that can make a request can start one, with a secret in the URL and a body the flow can read.
And on a schedule: nightly, weekly, first of the month. Scheduled work goes on a queue that survives a redeploy, so a job due at 02:00 during a deploy still runs rather than quietly not happening.
- A generated endpoint per flow, with its own secret
- Scheduled runs on a durable queue, leased so they run once
- Every run recorded: when, what matched, what it did
- Repeated failures disable the flow and say so
Automate one thing and see
Pick the rule your team most often forgets. Type it as a sentence. Read the dry run. That is the whole evaluation.