SFMC journey troubleshooting: trace the audience before changing the journey.

Write down what the journey should do

Define the qualifying event, the eligible audience, the intended message and the conditions that should prevent or stop the send. Be explicit about whether the same person can return to the journey and when.

Separate three questions: who is eligible, who actually entered and who received a send. Those populations are connected, but they are not automatically identical. A missing email is not enough evidence to conclude that the contact never entered.

Check the audience before the journey canvas

Review the source records, query joins, date filters and exclusions. Then inspect the target data extension schema, keys and write action. Check when the query completed and whether the entry source was evaluated against the output you expected.

A useful troubleshooting record shows the source count, eligible distinct contact count, target rows and the time each was produced. If counts disagree, explain the difference before treating one of them as the correct answer.

• Is each row at the intended customer or event level?
• Can a join multiply rows for one contact?
• Are contactability and suppression rules included?
• Is the data fresh enough for the entry schedule?

Inspect contact identity and repeat entry

Journey Builder evaluates identity using Contact Key. Two rows with the same email address but different keys are not automatically treated as one person. Review the identity mapping across the source, sendable data extension and journey.

The selected entry mode also matters. Re-entry at any time can allow a contact to have overlapping journey instances. Choose the mode that matches the business rule, then check other active journeys that can send a similar message. Preventing repeat sends requires understanding all relevant entry paths.

Trace a small set of real scenarios

Use representative test records for a qualifying contact, an excluded contact, a returning contact and a contact whose data changes during the journey. Record what you expect before running the tests.

Follow each record through query output, entry evaluation, decisions, exits and send evidence. Capture the active journey version and relevant timestamps. Preserve the evidence and change one identified cause at a time so you can tell which fix affected the result.

Test the content separately from the journey

A contact can enter correctly and still receive the wrong personalised content or a broken layout. Check the data used by AMPscript, missing-value fallbacks and the language or content variant assigned to the record.

Subscriber preview helps validate content against a record. It does not reproduce every email client or operating system. Test the agreed Outlook, Gmail, Apple Mail and mobile combinations separately; use the same representative content and data for each test.

Check the automation chain and leave a recovery path

If data arrives late or a query fails, a correctly configured journey can still use an incomplete audience. Review the imports, query dependencies, schedules and completion evidence behind the entry source. Set available failure notifications and document who responds.

End the fix with a repeatable test record: expected and actual audience, entry behaviour, content and send outcome. Keep a short recovery note for failures and a checklist the next campaign owner can reuse. Operational reliability starts with an explainable path from source data to send.