Journey QA Checklist for Journey Builder
A reusable QA checklist for Journey Builder: what to test before activation, how to build a test case matrix, and what to watch in the first days live.
A journey that passes a quick preview can still go wrong in production. Contacts enter twice, a decision split routes everyone down the default path, or a wait step releases thousands of emails at 3am local time. Once a journey is active, some of these mistakes cannot be undone, because the emails have already gone.
This checklist is organised in the order a contact experiences a journey: entry, path, content, sends and exit. Use it alongside a written test case matrix, and have someone other than the builder sign it off.
Entry and audience
| Check | What to confirm |
|---|---|
| Entry source | The data extension, API event or CRM event is the one in the design, and its filter criteria match the brief |
| Record evaluation | For data extension entry, you know whether the schedule evaluates new records only or all records each run |
| Re-entry setting | No re-entry, re-entry anytime or re-entry only after exiting is chosen deliberately and documented |
| Contact key | The entry source maps the correct field to Contact Key, matching Subscriber Key elsewhere in the account |
| Suppression | Exclusion criteria or suppression lists are applied where the design needs them |
| Volume | Expected entry volume per run is known, so you can spot a filter that is far too broad |
Path logic and timing
| Check | What to confirm |
|---|---|
| Decision splits | Every branch has a test contact that should reach it, including the remainder path |
| Engagement splits | The referenced email is the right one and the wait before the split gives people time to engage |
| Attribute sources | Split fields come from journey data or contact data intentionally; you know which values are fixed at entry and which are read at the moment of the split |
| Wait steps | Durations, specific dates and time zones are correct, and waits do not release large batches at bad hours |
| Goals and exit criteria | Goal criteria and exit criteria are set, tested, and do not remove contacts too early |
| Update activities | Update Contact or object activities write to the right fields and do not overwrite good data with blanks |
Build a test case matrix
A checklist tells you what to check. A test case matrix proves you checked it. Create one row per path through the journey, with a named test contact that should follow that path. Seed contacts should use addresses you control, for example qa+path-a@example.com, and carry the exact attribute values needed to reach each branch.
Journey Builder's test and preview tools are useful but do not replace live tests with seed contacts. Where your edition offers a journey test mode, use it, then still run the matrix against real entry data in a non-production business unit or with a tightly filtered seed audience.
Example test case rows
| Test ID | Test contact | Setup | Expected path | Result |
|---|---|---|---|---|
| J-01 | qa+gold@example.com | Tier = Gold, opted in | Gold branch, email 1 then email 2 after 3 days | Pass or fail with notes |
| J-02 | qa+standard@example.com | Tier blank, opted in | Remainder path, default content | Pass or fail with notes |
| J-03 | qa+unsub@example.com | Unsubscribed in All Subscribers | Enters but receives no commercial email | Pass or fail with notes |
| J-04 | qa+purchase@example.com | Purchase recorded after email 1 | Meets goal and exits before email 2 | Pass or fail with notes |
| J-05 | qa+reentry@example.com | Added to entry source twice | Behaves as the re-entry setting says | Pass or fail with notes |
Content and send settings
| Check | What to confirm |
|---|---|
| Email versions | Each email activity points to the final approved version, not a draft copy |
| Personalisation | AMPscript and personalisation strings render for full, partial and empty data |
| Send classification | Commercial and transactional classifications are correct for each message |
| Sender profile | From name, From address and reply-to match the brand and the authenticated domain |
| Publication list | The right publication list is selected so unsubscribes are honoured at the right level |
| Links and tracking | Every link resolves, carries the agreed tracking parameters and opens on mobile |
| SMS or push | Keywords, character counts, opt-in status and quiet hours are checked where used |
Questions we hear
Can we edit an active journey?
Who should run QA?
How many test contacts do we need?
Should we test in production?
After activation
- Watch the first entry run. Compare actual entry counts with the expected volume. A big difference usually means a filter or schedule problem.
- Check the first sends. Open the seed copies, confirm content, and confirm send logs and tracking show the expected counts.
- Review errors and exits. Look at contacts stuck in waits, contacts who exited early and any activity errors in the journey history.
- Record sign-off. Store the completed checklist and matrix with the journey version number so the next change has a baseline.
Related reading
- Testing journeys before activation explains the method behind this checklist
- Journey Builder decision splits vs engagement splits
- Throttling and send windows in Journey Builder
- Journey Builder consulting and Salesforce testing and QA
Launching an important journey?
We can review the design, build a test matrix and run independent QA before you activate.
