Book a demo →
How-to

Create and activate an automation

Build an automation by choosing its trigger, adding the steps it should run, then testing it before it goes live. A new automation starts inactive on purpose — validate the trigger, do a dry run that changes nothing, and only then activate it.

Requirements: a role that can manage automations. If the automation sends mail, a connected mailbox; if it acts on a collection, access to it.

Steps

  1. Choose the trigger. Decide the moment it should run — an entry created, a field or stage changed, a schedule, an incoming webhook or email, or a manual start. The trigger decides everything downstream, so be specific: "when a work order moves to Done", not "when a work order changes". The full set, and the origin setting that decides which changes it listens to, are in automation triggers — worth reading before you build, because the default surprises people.
  2. Add the steps. Lay out what should happen — send an email, update or create an entry, move a stage, call an external service, wait, or branch. One step is the starting point; the rest follow from it along the connections you draw between them, so the order on screen is not what decides the flow.
  3. Make optional steps conditional on the step itself. When you want "do this only if X, otherwise carry on", put the condition on that step rather than splitting into branches — see the warning below.
  4. Validate the trigger. Check the trigger configuration on its own first; it is the cheapest error to find and fix.
  5. Do a dry run. This walks the whole automation without changing anything and without sending anything — steps with side effects report what they would do. Use it to confirm the shape is right.
  6. Activate it. A new automation is inactive until you turn it on. Until then it will not fire, no matter how many times the trigger event happens.
  7. Run it once and inspect. Trigger it manually or wait for a real event, then open the run and check step by step what fired and what it did.

Dry run or test run?

They are not the same and the difference matters. A dry run changes nothing at all — nothing is saved, no mail leaves, side-effect steps only report their intent. Use it while you are still shaping the automation. A test run actually executes and records a run marked as a test, which you can then inspect in full. Use it when you want to see real behavior, and remember it is real: if a step sends mail, mail is sent.

The mistake to avoid

The most expensive error in automation building is branches that split and then rejoin. When a condition sends the flow down one path, the other path never runs — so a step placed after both paths converge waits forever for something that will never arrive, and the run hangs indefinitely. No validation catches this for you.

The fix is the habit in step 3: if the point is "do this one thing only when the condition holds, then carry on", attach the condition to that single step instead of branching. Reserve real branches for paths that genuinely end separately.

Notes and limitations

  • New automations are inactive. Nothing runs until you activate — the most common "my automation did not fire".
  • Record triggers listen only to website-origin changes by default, so a manual edit will not fire one until you add manual as an origin — see automation triggers.
  • A dry run persists nothing; a test run does, and sends what it says it sends.
  • Exactly one step is the entry point, and the flow follows the connections you draw — not the order steps appear in.
  • Email steps need sending limits set — a daily cap and a per-mailbox cap — and they are required, not optional.
  • A step-level condition sees only the record that triggered the run, so it cannot test what a field changed from, and it has nothing to read on a scheduled run.
  • Weekend-skipping and department-hours options apply to scheduled triggers only.

The model behind triggers, steps, and conditions is in agents and automations from first principles, and the trigger reference in automation triggers. If one does not fire or never finishes, work through my automation did not run. Automations act on the model you built — see collections and fields — and can send from your connected mailbox using a template.

Frequently asked questions

My automation never runs.
Most often it was never activated — new automations start inactive. After that, check the trigger really matches the event, then open the run history to see whether it fired and where it stopped.
What is the difference between a dry run and a test run?
A dry run changes nothing and sends nothing — side-effect steps only report what they would do. A test run really executes and records the run, so mail actually goes out.
My run started but never finished.
Almost always branches that split and rejoin: the step after the rejoin waits for a path that never ran. Use a condition on the step instead of branching around it.