Testing workflows before going live
A broken workflow can damage your customer relationships in seconds — wrong merge fields, dead links, mistimed messages. Test every workflow before publishing it.
The 5-step test protocol
1. Add yourself as a contact (with your real personal phone and email)
2. Add the test tag (e.g., "workflow-test") to your test contact — most workflows can be triggered by adding the right tag
3. Open the workflow's Execution History to watch it run
4. Receive the messages on your phone and inbox — read them as a customer would
5. Spot-check: merge fields filled correctly, links work, timing makes sense, tone matches your brand
What to check on every message
Merge tags actually filled in (no "Hi " with literal brackets)
Links work and lead to the right pages
From-email is your verified sending domain, not a generic platform address
Tone fits your brand voice (no canned-template sound)
SMS under 160 characters where possible (or you accept the multi-segment cost)
No internal-only language leaked into customer messages
Drift testing
After a workflow has been live for 30 days, re-test it. Things drift: a merge field gets renamed, a custom value updates, your business hours change. Drift is silent until a customer points it out.
TIP — Use a test pipeline stage
Create a test pipeline stage called "QA Testing." When you want to test stage-triggered workflows without real customer impact, move a test contact's opportunity to that stage. Real customers never see this stage; your team uses it for safe testing.
Soft launch with real customers
After QA passes, soft-launch with a small audience before scaling:
1. Use a condition to limit the workflow to a specific tag for the first 48 hours
2. Add 5–10 friendly real contacts to that tag
3. Monitor execution history and any reply behavior
4. If everything looks healthy, remove the limiting condition and let the workflow run for everyone
