Debugging Journey Entry and Re-entry Problems

Almost every journey escalation I get starts the same way: "the contact is in the data extension, but they never entered the journey." It is rarely one bug. It is usually three or four ordinary rules stacking up in a way nobody drew on the whiteboard.

Entry event and entry filter are not the same thing

The entry source decides which records are evaluated. The entry filter decides which of those evaluated records continue. A record can be picked up by the entry source and quietly dropped by the filter a second later, and the two look identical from the outside — nothing happened.

The first question I ask is therefore not "why didn't it enter?" but "was it ever evaluated?" Those have different answers and different fixes.

The usual suspects, in the order I check them

• The journey version that is actually running is not the version you are looking at.
• The contact already exists in the journey, and re-entry is set to no re-entry.
• The record arrived in the data extension before the journey's schedule window opened.
• The entry filter tests a field that is null rather than the value you expected.
• The contact is excluded at send time by an exclusion script or a suppression list — so they did enter, they just never received anything.

Re-entry modes, plainly

No re-entry means a contact who is currently in the journey cannot start again. Re-entry anytime means they can be in the journey more than once at the same time — which is exactly what you want for an order confirmation and exactly what you do not want for an onboarding series. Re-entry only after exiting is the middle option most people actually mean when they say "let them come back."

Contacts who have completed the journey in a previous version still count as having been in it. That surprises people mid-migration more than anything else on this list.

A query I keep around

SELECT
  s.SubscriberKey,
  s.EmailAddress,
  s.CreatedDate
FROM JourneyEntrySource s
WHERE s.SubscriberKey = 'SAMPLE-001'
ORDER BY s.CreatedDate DESC

It is deliberately dumb. Before theorising about filters, confirm the record exists, when it landed, and what the fields contained at that moment — not what they contain now. Journey Builder evaluated the row as it was, and a nightly update may well have rewritten your evidence.

A short checklist

• Confirm the running version, not the draft.
• Confirm the record existed before evaluation, not after.
• Read the entry filter as a null-safety exercise first.
• Check re-entry against the behaviour you actually want, not the default.
• Separate "never entered" from "entered and never sent" before doing anything else.