Runs and tests
Once the flow is built, two questions always follow: “does this work?” and “what happened to that contact?”. Both are answered in the same place — the Test button at the top of the editor, and the Activity section in the left rail.
Testing
Section titled “Testing”
A test runs the flow against a real conversation or contact, but with sending actions simulated: nothing reaches the customer.
What to test
Section titled “What to test”- Current canvas — what’s in the editor right now, even if it was never saved. It’s the default, and it’s what makes it possible to check an edit before committing it.
- Live version — what your contacts are receiving right now. It only appears once a version has been saved.
The target
Section titled “The target”What the dialog asks for depends on the trigger you chose to simulate:
- conversation triggers ask for a conversation;
- contact triggers ask for a contact;
- when the automation has more than one trigger, you pick which one to simulate.
Without a target the test still runs, and the steps that depend on a conversation or contact fail — which is exactly what the test is there to show.
What’s simulated and what isn’t
Section titled “What’s simulated and what isn’t”| Step | In a test |
|---|---|
| Send message, Send email | simulated — the step’s output shows what would have been sent |
| Call webhook | simulated |
| Analyze with AI | runs for real and consumes credits |
If the flow has anything to fix, the test doesn’t even start: the errors come back per step and light up on the canvas, just like the save validation.
Activity
Section titled “Activity”
The Activity section keeps every time the automation ran. The list shows when, which trigger, the status and the cost — test runs carry a Test badge.
The statuses
Section titled “The statuses”| Status | What it means |
|---|---|
| Queued | created, waiting for the engine to pick it up |
| Running | walking through the steps right now |
| Waiting | paused on a Wait step, until wake-up time |
| Completed | reached the end of the path |
| Failed | a step broke; the error shows in the timeline |
| Canceled | ended by an exit condition on a Wait step |
The engine checks the queue every minute. A freshly fired automation shows up here in seconds; one waiting three days moves again in the minute after the deadline.
Path taken
Section titled “Path taken”With a run selected, the canvas shows where it went, with the steps that didn’t happen dimmed. It’s the fastest answer to “why did the branch go the wrong way”.
The drawing is always of the version that run executed on, not the draft open in the editor. An old run stays readable after you rework the flow.
Just below, Entered through says which trigger started that run — information that matters when the automation has more than one.
Timeline
Section titled “Timeline”Step by step, with the time, the status and — what matters most — each step’s input and output, in JSON.
That’s where you find out what the AI actually returned, what the message would have sent ("simulated": true in a test) and why a send didn’t happen. When a sending safeguard blocks a message, the step doesn’t fail: it’s marked as skipped and the output carries the reason, under one of these names:
| Reason | What happened |
|---|---|
contact_opted_out | the contact asked to stop receiving messages |
conversation_snoozed | whoever is handling the conversation snoozed it |
customer_awaiting_reply | the customer spoke last and is waiting on your team |
frequency_cap | the contact already got 3 automated messages in the last 24 hours |
meta_window_closed | 24h passed without a reply and no approved template was chosen |
The Cost column adds up the credits consumed by that run. In practice, that’s the cost of Analyze with AI steps — no other step consumes credits.
The history dies with the automation. Deleting an automation deletes every version and every run along with it. If the history matters, turn it off instead of deleting it.