How do I test a workflow before turning it on?
Short answer
Testing a workflow before turning it on means running a real contact through every path it can take and checking each message and action as a customer would experience it. Use a test contact with a real phone and email, trigger the workflow manually, walk every branch, and only publish once every path behaves as expected.
Before you start
- A workflow built and ready to publish, including any branches or wait steps.
- A test contact with a real phone number and email address you control.
- A list of the different paths the workflow can take, including branches and exits.
- Enough time to wait through any short delays built into the workflow.
Step by step
- 1
List every possible path through the workflow
Write down each branch, exit condition, and variation the workflow can produce, not just the main happy path.
A workflow that only gets tested on its simplest path often breaks on the paths nobody thought to check.
- 2
Use a test contact you fully control
Set up or use an existing contact with a phone number and email you personally have access to, so you can see every message exactly as sent.
Testing with a fake or unreachable contact hides problems that only show up in delivery.
- 3
Trigger the workflow manually
Start the workflow using the same trigger event a real contact would hit, or add the test contact directly if the platform allows a manual enrollment.
Triggering it the real way catches trigger misconfiguration, not just problems inside the workflow itself.
- 4
Read every message as the customer would receive it
Check spelling, merge fields, tone, and links on an actual phone and inbox, not just in the workflow builder's preview.
Broken merge fields and awkward previews are easy to miss until you see the real message land.
- 5
Walk every branch, not just the default one
Use separate test contacts or repeated runs to trigger each branch's condition and confirm each path sends the right messages.
The branch nobody tests is the one that ships broken.
- 6
Verify wait steps fire at the right time
Check the timestamp on each message against the wait duration configured, especially for anything measured in days.
A wait step set to the wrong unit can send a week's worth of follow-up in minutes.
- 7
Trigger any exit conditions on purpose
Reply to a message, book an appointment, or take whatever action should stop the workflow, then confirm no further steps fire.
An exit condition that silently fails to work is often worse than having no exit at all.
- 8
Watch the first live runs after publishing
Even after thorough testing, check the first several real contacts that go through the workflow once it is live.
Real customer data occasionally surfaces an edge case that a single test contact never hit.
What good looks like
- Broken messages, wrong timing, and missing exits get caught before a real customer ever sees them.
- Every branch in the workflow gets verified, not just the default path.
- The team gains confidence to turn on more automation because testing is a repeatable habit.
- Fewer emergency fixes are needed after a workflow goes live.
Common mistakes
The ways this goes wrong in automation, and what to do instead.
Only checking the builder's preview screen›
A preview inside the workflow builder often hides broken merge fields, bad line breaks, and links that behave differently on a real phone.
Do this instead: Trigger a real send to a phone and inbox you control before publishing.
Testing only the main path›
Skipping branch and exit conditions during testing means those paths run live completely unverified.
Do this instead: List every branch and exit and test each one individually before publishing.
Rushing through wait steps without checking timing›
Assuming a wait step is set correctly without checking the actual delivery timestamps can let a unit mistake slip through unnoticed.
Do this instead: Compare message timestamps against the configured wait duration during testing.
Never watching the first live runs›
Even a well-tested workflow can behave differently against real customer data with edge cases a single test never hit.
Do this instead: Check the first several real contacts after publishing before considering the workflow done.
Frequently asked
6 questions about test a workflow before turning it onRelated guides
Pick the next thing to set up, or back up a step if something here assumed work you have not done yet.
Do this next
The natural follow-on tasks once this one is working.
People usually get here from
Guides that lead into this one, in case you skipped a step.
More in Automation
Nearby tasks that share the same setup and vocabulary.
Was this guide helpful?
Tell us what worked and what didn't. It shapes what we rewrite next.
You didn't get into business to be in the tech business.
Managed Tech clients hand this to us. We build it, test it, maintain it, and add to it as the business changes, so nobody on your team has to become the person who knows how the system works.