Journey Builder Entry Source Data Extension: How to Build It

You have an audience in mind, and now Journey Builder asks you to pick an entry source. If you choose a data extension, the quality of that table decides who gets in, how often, and whether anyone gets the same email twice.

A Journey Builder entry source data extension is a sendable data extension that Journey Builder reads on a schedule to admit contacts into a journey. The reliable way to build one is a SQL query activity that writes qualified, deduplicated contacts into a dedicated sendable data extension, then a schedule that evaluates it.

‍

This guide covers what the documentation requires, a complete SQL example, which schedule to pick, and the pitfalls that cause silent failures.

‍

What a Journey Builder entry source data extension actually is

‍

The short version

The data extension entry source admits contacts to a journey from an existing data extension, on a schedule. You can filter the records going in, or admit all of them.

It suits batch sends, recurring programs and complex segmentation. It is not the right tool for real-time, one-to-one messages such as a form confirmation, where an API or event-based entry fits better.

‍

In practice, most teams point Journey Builder at a table that a query activity maintains. That keeps the audience logic in one visible place, makes it testable, and lets you change the rules without touching the journey canvas.

‍

What Salesforce asks you to prepare

The official Trailhead guidance on preparing the entry source is short and worth following to the letter:

• Use a sendable data extension.
• Include every field you need for personalization or dynamic content.
• If your data lives in several data extensions, combine it into one with a query activity in Automation Studio.
• Pre-filter the data extension where possible to speed up processing.
• Link the data extension into the data model in Contact Builder when it applies.

Also remember that entry data is a snapshot of the contact's attributes at the moment of entry. It does not change while the contact moves through the journey. Source: Trailhead, Prepare the Entry Source.

‍

How to build the audience with SQL

‍

A complete example: a win-back journey entry table

Say you want to enter customers into a win-back journey when their last purchase is more than 180 days old, they are still active subscribers, and they have never been admitted before. The query below builds that table.

SELECT
    c.SubscriberKey,
    c.EmailAddress,
    c.FirstName,
    c.LastPurchaseDate
FROM Customers_Master c
INNER JOIN _Subscribers s
    ON s.SubscriberKey = c.SubscriberKey
WHERE s.Status = 'active'
    AND c.LastPurchaseDate < DATEADD(DAY, -180, GETDATE())
    AND NOT EXISTS (
        SELECT 1
        FROM Winback_Journey_Entry e
        WHERE e.SubscriberKey = c.SubscriberKey
    )

Target data extension: Winback_Journey_Entry, sendable, with SubscriberKey as the primary key. Update type: Append.

‍

The query, line by line

• The first four selected columns are the personalization fields the journey emails will need, plus the key and the email address.
• The join to the subscribers data view keeps only contacts whose status is active, so unsubscribed or bounced contacts never reach the entry table.
• The date condition keeps customers whose last purchase is older than 180 days. See our guide to SFMC SQL date functions if you need to handle time zones.
• The NOT EXISTS block compares against the target table itself, so someone already admitted is never added twice.
• Append adds only the new rows, which is what makes a "new records only" evaluation safe. The trade-offs are explained in Overwrite vs Update vs Append.

If you would rather not write this by hand, you can generate SFMC SQL from plain English and review the result before you run it.

One more design choice is worth making early: keep the entry table narrow. Carry only the key, the email address and the fields the journey truly needs. Wide tables slow down evaluation, and every extra column is another thing that can drift out of sync with your source data.

‍

Choose the schedule: run once, recurring or automation

‍

The three schedule types

Run Once admits contacts when the journey is activated, or at a date and time you set. Recurring admits contacts at an interval you choose. Automation admits contacts when a selected Automation Studio automation completes.

Automation is the best fit when a query regularly rewrites the data extension, because the journey evaluates the records only after the data is fresh. The automation must include an import, filter or query activity that directly modifies the data extension. Source: Salesforce Help, Data Extension Entry Source.

‍

New records only or all records

On a repeating schedule you choose how records are processed. Evaluate new records only looks at contacts added since the previous run. It is meant for sources where rows are appended without deleting or overwriting existing ones, and it is usually faster.

Evaluate all records checks every row on every run. Use it only when records are continually updated. Salesforce specifically advises against combining a filtered data extension with the new records only option, because refreshing a filtered data extension overwrites all records.

‍

Quick answer: your entry source checklist

‍

1. Create a dedicated sendable data extension with a primary key on SubscriberKey and an EmailAddress field.
2. Add every personalization field the journey needs.
3. Write one query activity that joins your sources, filters the audience and excludes people already admitted.
4. Set the query to Append if you plan to evaluate new records only, otherwise Overwrite.
5. Put the query in an automation and schedule it before the journey evaluates.
6. In Journey Builder, pick the data extension, choose the schedule and the record option, and set a default email address.
7. Check the re-entry setting before you activate.

Situation	Update type	Record option
Rows only ever added	Append	New records only
Table rebuilt every run	Overwrite	All records
Rows edited in place	Update	All records

‍

Pitfalls that cause silent failures

‍

Skipped runs and stale counts

If records are still being evaluated when the next scheduled run is due, that run is skipped and the records are processed in the following run. Large tables and short intervals are the usual cause.

The Record Count tile also shows what is in the data extension right now, which may differ from the records evaluated for entry if the data changed after you scheduled. Use View Event Results to see what actually entered in the last 30 days.

‍

Re-entry and the contact key

Re-entry is a journey-level setting with three options: no re-entry, re-entry only after exiting, and re-entry anytime. A welcome journey usually uses no re-entry, while a recurring win-back program may need re-entry after exit.

On entry, the system creates a contact using the Subscriber ID as the Contact Key. Make sure your SubscriberKey values are consistent across your sources, or the join will quietly drop people. Our guide to building a reactivation audience covers the audience logic in more depth.

‍

Testing before you activate

Run the query activity once and open the target data extension. Confirm the row count looks plausible, spot-check a handful of SubscriberKey values against your source, and make sure no EmailAddress is empty. A five-minute check here saves a journey full of contacts who cannot receive anything.

If you use a recurring schedule, run the automation twice and confirm that the second run adds only genuinely new people. That is the quickest proof your exclusion logic works.

‍

Large tables that time out

If the query feeding your entry table runs for too long, the whole chain stalls. Pre-filter early and avoid scanning the full data views. See why SFMC SQL queries time out and how to fix them.

‍

FAQ

‍

Does the entry source data extension have to be sendable?

Salesforce guidance is to use a sendable data extension. A sendable data extension has a send relationship that maps one of its fields to Subscriber Key, which is what lets Journey Builder email the contacts in it.

‍

Can I use a filtered data extension as an entry source?

You can, but not safely with the new records only option. A filtered data extension is overwritten on refresh, so Salesforce recommends against that combination. A query activity with Append is more predictable.

‍

How often can the entry source be evaluated?

A recurring schedule lets you choose the interval, and an automation schedule evaluates the data when the automation completes. Pick the cadence your data refresh actually supports.

‍

Why did nobody enter my journey?

Check that the journey is activated, that the schedule has started, that the data extension actually contains rows after your query ran, and that the re-entry setting is not blocking people who entered before.

‍

Build this audience in seconds with QAiry

‍

The query above is simple once you know the pattern, but the join, the exclusion and the right update type are easy to get wrong under deadline. QAiry turns a plain-language request into production-ready SFMC SQL and Data Extensions, installed as an app in your own Marketing Cloud, so you can review the query before it runs.

Ready to try it? Install QAiry for free or see a product demo.