Testing an automation without messaging real customers
Almost nobody writes about this, and it is the difference between a flow that works and one that embarrasses you at scale.
Testing an automation means proving each path does what you intended before the flow is published, using the simulator for logic and your own phone for the parts only a real device shows. An unpublished flow sends nothing, so all of this is safe by construction.
This is the least-written-about part of WhatsApp automation and one of the most consequential. A flow that misfires does so on every matching conversation simultaneously.
The four stages
| Stage | Catches | Risk to customers |
|---|---|---|
| 1. Read the canvas | Unwired branches, missing handovers | None |
| 2. Simulate | Logic errors, empty variables, wrong routing | None |
| 3. Your own phone | Copy that reads badly, timing, real rendering | None |
| 4. Publish, watch closely | Everything else | Real |
Stage 1 — read the canvas before you run anything
- Does every branch go somewhere? A question option with nothing wired to it leaves the customer in silence.
- Is there a path to a human? On every failure branch and every menu.
- Does anything read a variable before something writes it? On branching flows this is easy to build by accident, and it always produces an empty value.
- Is there a cooldown or a first-message check on anything triggered by a customer message?
Stage 2 — simulate
The builder's Simulate mode walks the flow as if you were the customer, running the real conditions and showing what each step would send, without sending anything.
Walk every path, not just the happy one. The bugs live on the branches you did not think about: the customer who taps "cancel", the lookup that finds nothing, the question answered with an emoji.
Watch specifically for variables rendering as blanks. A message that reads "Hi , your order is on its way" in the simulator will read exactly like that on a customer's phone, and the usual cause is a contact field that was never defined.
Stage 3 — message your own shop
The simulator proves logic. It does not tell you that your message is a wall of text on a phone screen, that your three button labels are truncated, or that the tone is wrong.
- Publish the flow while your team is watching, or use a quiet period.
- Message your shop number from your personal phone.
- Type the way a rushed customer types — lowercase, misspelled, abbreviated. If your keyword list only matches perfect spelling, you want to know now.
- Tap through every button.
- Deliberately do the wrong thing: answer a button question with free text, send a photo where text is expected, go silent halfway through.
Testing a template flow is harder, and it is worth being honest about why. A flow triggered by a Shopify order needs a real order to fire, and it sends an approved template rather than free text. The practical approach is a real test order on your own store, placed with your own phone number, then cancelled. There is no way to fire a store event by hand.
Stage 4 — publish and watch
Each automation has an activity view showing every run, which conditions passed, and where a run stopped. For the first day of a new flow, this is the thing to check — not your inbox.
What to look for:
- No runs at all. A condition is blocking everything, usually a keyword list that does not match real phrasing.
- Runs that stop early. The view names the step. Often a lookup whose failure branch was never wired.
- Runs that complete but customers reply confused. A copy problem, not a logic one.
Publishing safely
Three habits that reduce the blast radius:
- Publish the narrow version first. A keyword rule with three specific keywords is safer to launch than a catch-all that answers everything.
- Publish early in your working day, not last thing before a weekend. If it is wrong, you want to be there.
- Remember that editing a live flow changes nothing until you publish again. A fix made at lunchtime is not protecting anyone at dinner unless you pressed the button.
Why a draft is genuinely safe
An unpublished automation does not run. That is also why installing a ready-made flow is safe — it arrives as a draft, and nothing reaches a customer until you have read every step and published it deliberately.
A related protection: a flow whose template step has no approved template selected cannot be published at all. The publish is blocked with an explanation rather than going live and failing silently — which matters, because a template mismatch produces error 132000 and the customer receives nothing.
What to re-test, and when
Automations rot quietly. Re-test when any of these change: a template's variables, your opening hours, a Google Sheet's column headings, your knowledge base content, or your team structure. All five break a flow without producing an error anywhere you would naturally look.
A twenty-minute pass through the simulator once a quarter is cheaper than the alternative, which is a customer telling you.
Frequently asked questions
Can I test a WhatsApp automation without messaging real customers?
Yes. An unpublished flow sends nothing, and the builder's Simulate mode walks every path with the real conditions without sending a message.
How do I test a flow triggered by a Shopify order?
Place a real test order on your own store with your own phone number, then cancel it. There is no way to fire a store event by hand.
My automation published but never runs. What is wrong?
Check the automation's activity view. No runs at all means a condition is blocking everything — most often a keyword list that does not match how customers actually phrase things.
Do edits to a live automation take effect immediately?
No. Edits become unpublished changes until you publish again, so a fix is not protecting anyone until you press the button.