Why an automation or workflow did not run
For an automation, read its health line. For a workflow, check it is both published and switched on.
Automations and workflows fail for different reasons, so start by knowing which you have. An automation is one Tideswell ships. A workflow is one somebody in your workspace built.
An automation did not run
Work down these in order.
Is the amber banner up? Automations switched off for the whole environment means nothing runs, whatever the individual cards say.
Is the card switched on? Most alerting automations ship switched off.
What does the health line say? It answers the question directly:
- Never run means it has not come round yet. Press Run now.
- No alert means it ran and there was nothing to report. This is the healthy state, and it is the most misread line on the screen.
- Failed names its reason.
- A skipped run names what was missing, usually a module switched off or a data source not connected.
Did it find things but notify nobody? Found 4, notified 0 means the recipient list is empty or nobody holds the required access. See How to choose who gets an alert and how often.
Full detail in How to check whether an automation worked.
A workflow did not run
Is it published, and separately, is it switched on? These are two independent controls and this is the commonest cause by a distance. A workflow's status can read published while its toggle is off, and it will not run.
Has enough time passed? Workflows are not instant: changes are picked up on a cycle of a few minutes, and a change originating in Shopify takes another poll to be noticed.
Did the record change in a way the trigger watches? A changed trigger with watched fields ticked ignores every other edit. See How to choose a trigger.
Is the Workflow engine automation switched on? Turning that one card off stops every workflow in the workspace at once.
Is the Automations module on? With it off, the whole section including workflows is unreachable.
The workflow ran but did the wrong thing
Open the Runs tab and read the run as a story. Each step says what it was set up to do and what it actually did.
Check which handle each line leaves from. A condition has a green Yes dot and a red No dot, and a line drawn from the wrong one produces a workflow that works perfectly at exactly the wrong moment. This is the most common build mistake and it is invisible once the canvas is tidy.
Read what the condition decided. The run says whether it matched and which path it took, which usually reveals that the comparison was not what you thought.
A run says cancelled
The loop guard refused it, and it says why.
That happens when a workflow has run repeatedly for the same record in a short window, which almost always means it is setting itself off: it updates a field on the triggering record, and that update re-triggers it.
Fix it by ticking watched fields on the trigger so only the fields that should cause a run do. Refused runs are dropped rather than queued, so they will not arrive later in a flood. See How to create tasks, records and links from a workflow.
A step failed but the rest worked
The run reads partially completed in amber, which is normal on a workflow with two branches.
Common step failures name themselves: a Notify aimed at a department with nobody active in it, a triggering record deleted before the run, or an action the workflow owner no longer has permission for.
That last one is worth checking after somebody leaves. Every action a workflow takes uses its owner's access, so a workflow owned by a departed colleague fails visibly. See What are workflows?.
Nothing at all has run since a settings change
Somebody probably switched off a module. Its automations go dormant and record skipped runs saying so.