Book a demo →
FAQ

My automation did not run

Work through it in this order: the automation is not active, the trigger is not listening to where your change came from, the trigger does not match what actually happened, a condition stopped the run, or it started and is stuck. The run history tells you which — whether a run exists at all is the first thing to look at.

Nothing happened. Before changing anything, check the automation's run history — it splits the problem in half. No run at all means the trigger never fired: causes 1 to 3. A run exists but did nothing useful: causes 4 and 5.

1. It is not active

New automations are created switched off, on purpose. An inactive automation never fires however many times the event happens. Fix: activate it. This is the most common cause by a wide margin.

2. The trigger is not listening to your kind of change

This is the one that catches nearly everyone. A record trigger filters on where the change came from — your website, a manual edit, an import, an integration, another automation — and by default it listens only to changes coming from your website.

So the classic test fails: you build an automation, edit a record by hand to check it, and nothing happens. The automation is fine; it is not listening to manual edits. Fix: add the origins it should react to — see automation triggers.

3. The trigger does not match what happened

A trigger watching one specific field does not fire when a different field changes. A stage trigger does not fire when someone edits a note. An opening-email trigger does not fire on replies, and a reply trigger does not fire on the first message.

Fix: compare what actually changed against what the trigger watches. If you want any edit, use the general update trigger; if you want one field, watch that field.

4. A condition stopped it

If a run exists but ended early, a condition probably decided against continuing — which is the condition doing its job. Fix: open the run and look at where it stopped; the step that ended it is visible, along with what it evaluated.

5. It started and never finished

A run that begins and then sits unfinished usually means branches that split and rejoined. When a condition sends the flow one way, the other path never runs — so a step placed after the two paths reconverge waits forever for something that will never arrive. Nothing warns you about this when you build it.

Fix: restructure so optional work uses a condition on the step itself rather than a branch that has to rejoin — covered in create and activate an automation.

Special cases worth knowing

  • Scheduled runs have no record attached, so steps expecting one find nothing. The steps must look records up themselves.
  • Bulk edits fire once for the whole batch, not once per record — so an automation that seemed not to run may have run a single time as designed.
  • Automatic replies never fire conversation triggers, which is deliberate.
  • Email steps can be held back if the mailbox's sending health has dropped — the run succeeded, the message is waiting. See connect a mailbox.

Trigger types and the origin setting are in automation triggers; building and testing safely in create and activate an automation; the wider model in agents and automations from first principles.

Frequently asked questions

How do I tell whether it fired at all?
Check whether a run exists at all. No run means the trigger never fired — look at activation and trigger settings. A run that exists means it fired and stopped somewhere you can inspect.
It works from the website but not when I edit by hand.
Record triggers listen only to website-origin changes by default. Add manual edits as an origin the trigger reacts to.
The run started but never completed.
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.