Troubleshooting an automation

Using run history and trigger events to isolate why a workflow misbehaved.

Updated Available on Free Agent Pro Agent Advanced Agent Enterprise

Two separate histories tell you almost everything:

  • Trigger event history — what arrived
  • Workflow run history — what the workflow did about it

The gap between them is where most problems live. If an event appears but no run does, the trigger fired and a condition stopped it. If neither appears, nothing arrived.

Run statuses are Waiting for trigger, Running, Completed and Failed.


It didn’t run at all

Is the workflow active? Start here. It’s the answer more often than anyone admits.

Are there incomplete nodes? A workflow with unconfigured nodes won’t behave reliably. The builder flags which ones.

Did the event arrive? Check the trigger’s event history. For Review triggers, nothing arrives if the source stopped syncing. → Fix a disconnected review source

Did a condition block it? The most common real cause. Walk each condition against the specific event.

Check your boundaries: LESS_THAN 3 excludes 3-star reviews. If you meant “3 and below” you want LESS_THAN_OR_EQUAL.

Check your matching: ALL requires every rule to pass. One wrong rule stops everything.

Have you hit your action limit? → Understanding actions and limits

It ran twice

Is one trigger driving two workflows? A trigger can be shared. Check whether another workflow uses the same one.

Do two workflows overlap? A general negative-review workflow and a specific one-star workflow will both fire on a one-star review. Exclude the specific case from the general workflow.

Did the event genuinely happen twice? Some platforms re-surface an edited review as new. An API or webhook integration retrying a failed call sends the event twice unless it’s idempotent.

It ran at the wrong time

Check the Wait durations. Units matter — 24 hours and 1 day are the same, 24 minutes is not.

Check what the trigger keys off. A Shopify customers create fires at purchase, not at delivery. That’s what the Wait step is for.

Check for a stacked delay. Two Wait steps in sequence add up. It’s easy to add a second and forget the first.

It did the wrong thing

Read the actual output. Open what was sent. “The AI said something odd” is hard to act on; the message itself usually makes the cause obvious.

Raw placeholder names in the message? The step is referencing data that isn’t available at that point in the flow — usually because the step was moved, or sits before the step that produces the data. → Personalising automated messages

Right message, wrong person? Conditions problem, not copy.

Polite but generic copy? Your business context is too thin. That’s fixed in workspace settings, not in the workflow. → Setting the tone

Replied to something sensitive? Add an escalation condition. → Safety rails

A run shows Failed

A failed run means a step errored rather than a condition stopping the flow.

Common causes: an action pointing at something that no longer exists (a deleted survey, a removed teammate), a disconnected integration for a Salesforce step, or a missing required value on a step that was edited.

Open the run, find the step that failed, and check its configuration.

Diagnosing methodically

  1. Find the event in the trigger history.
  2. Find the corresponding run — or confirm there isn’t one.
  3. Walk each condition against that event’s data.
  4. Check which steps ran and what each produced.

Four steps, and they isolate almost every problem to a specific node.

Testing safely

After changing anything: test to yourself, check the run completed as expected, then reactivate. → Testing and activating

Still stuck?

Contact us with the workflow name and the specific event you expected it to act on. That pair is usually enough for us to see the cause immediately.

Was this article helpful?

Still stuck? Talk to us — or open the chat in the corner.