The setup looked correct. The Journey was configured with a daily Automation Studio entry source, the SQL query was pulling only recent purchases, and Contact Evaluation was set to “Evaluate new records only.” When the Journey activated, it sent to every contact already in the Data Extension — including people who had made purchases weeks ago and should never have received that email.

This is one of those Journey Builder behaviors that seems like a bug but is actually documented platform behavior that almost nobody reads carefully enough before going live. We have seen it catch teams off guard repeatedly. The setting does exactly what it says — but only under specific conditions that most setups accidentally violate.

Journey Builder’s Contact Evaluation setting looks straightforward — but one upstream configuration decision renders it completely ineffective.

What “Evaluate New Records Only” Actually Does

When Journey Builder runs against a Data Extension entry source on a schedule, “Evaluate new records only” tells it to compare the current state of the DE against a snapshot of the DE from the previous run. Only records that did not exist in that previous snapshot are treated as new and injected into the Journey.

That comparison depends entirely on the DE having a stable state between runs. Journey Builder needs to look at what was there before and what has been added since. If something removes that historical state — if the DE’s previous contents are wiped before the comparison can happen — Journey Builder has nothing to compare against. Every record in the DE looks new because as far as it can tell, all of them just appeared.

The platform is not ignoring your setting. It is doing exactly what you configured. The problem is that the SQL action upstream is eliminating the condition that makes the setting work.

The Exact Scenario That Causes This

The typical broken setup looks like this. An Automation Studio automation runs daily. It contains a SQL Query Activity that selects all contacts who made a purchase, with the query action set to Overwrite on the target DE. Journey Builder is then triggered from that automation, using the same DE as the entry source, with Contact Evaluation set to “Evaluate new records only.”

The Fix

The cleanest solution is to change where the filtering happens. Instead of putting all historical records into the DE and relying on Journey Builder to determine which ones are new, you build the incremental logic into the SQL query itself. The DE then only ever contains the records you actually want the Journey to process on that specific run. With that in place, you switch Journey Builder to “Evaluate all records” — because every record in the DE is already a new one by definition.

/* Pull only contacts who made a new purchase in the last 24 hours.
   DE action: Overwrite.
   Journey Contact Evaluation: Evaluate all records.
   Every record written here is a genuinely new purchaser. */

SELECT
    p.SubscriberKey,
    p.EmailAddress,
    p.FirstName,
    p.PurchaseDate,
    p.ProductName,
    p.OrderValue

FROM Purchase_Events p

WHERE p.PurchaseDate >= DATEADD(day, -1, GETDATE())
  AND p.PurchaseDate <  GETDATE()

The First Run Problem

There is one additional edge case worth knowing about. Even with the correct setup, the very first run after you activate a Journey has no previous snapshot to compare against regardless of what approach you use. SFMC handles this with a specific setting that appears during activation: you can choose whether the first run processes all records currently in the DE or skips them entirely and only picks up records from the next run onward.

If your DE already has records in it at activation time and you choose “all records” for the first run, those contacts will enter the Journey. This is expected behavior and is actually documented — but it surprises people who assume “evaluate new records only” protects them at activation too. It does not. Clear the DE before activating, or choose “new records only” for the initial run, if you do not want the existing population to enter.

The data action setting inside the SQL Query Activity — this single dropdown is what determines whether Journey Builder’s “new records” evaluation works or is silently bypassed.

Frequently Asked Questions