How to Build Dynamic Audiences in SFMC

‍

Most CRM teams know the difference between a one-time list and an audience that keeps itself up to date. Building the second kind in Salesforce Marketing Cloud is where things tend to get awkward.

The platform gives you several ways to do it. Filtered Data Extensions, filter activities, SQL Query Activities, and Journey Builder entry sources all promise dynamic behavior, and each one behaves a little differently in production.

This guide walks through what dynamic actually means inside SFMC, the native tools you have to build live audiences, and the trade-offs that decide which one you reach for.

‍

What dynamic actually means in SFMC

‍

Static lists versus dynamic audiences

A static list is a fixed set of contacts at a moment in time. You build it once, send to it, and move on.

A dynamic audience is a definition, not a snapshot. The same query or filter is re-evaluated whenever you refresh the underlying data extension, so the contents shift as your data changes.

In SFMC, that distinction is enforced by the platform. A regular sendable data extension holds whatever rows you imported last; a Filtered Data Extension recomputes from its source whenever it is refreshed.

‍

Why this matters for sends

Static lists drift the moment new contacts arrive or existing ones change status. Dynamic audiences solve that, but only if the refresh actually runs before each send.

The number of "why did this contact get the email" tickets you receive is usually a function of how reliable your refresh schedule is, not how clever your segmentation logic is.

‍

The native tools for dynamic audiences

‍

Filtered Data Extensions

A Filtered Data Extension creates a subset of an existing data extension based on a saved filter. The result lives as its own data extension, sendable, with its own subscriber count and preview.

Filtered Data Extensions are the lightest way to build a dynamic audience in SFMC. You point at a source, define a filter in the visual builder, and the platform handles the rest.

They are best suited to audiences that can be expressed against a single source DE without joins or aggregations.

‍

SQL Query Activities

When you need joins, aggregations, or logic that spans multiple data extensions or data views, a SQL Query Activity in Automation Studio is the right tool.

The query writes its result into a target data extension. That target is what you send to, journey-trigger on, or feed into downstream activities.

SQL queries are more flexible than filter activities and harder to maintain. Every team that has worked in SFMC for more than a year has a folder of _Sent, _Open, and _Click joins that nobody wants to touch.

‍

Journey Builder entry sources

Journey Builder entry sources are a quieter form of dynamic audience. A data extension entry source re-evaluates on a schedule and admits new contacts as they qualify, which makes the journey itself behave like a rolling audience.

The trade-off is that journey-driven audiences are coupled to a specific journey. If you need the same audience for an ad sync or a one-off send, you usually still want the underlying data extension to be the source of truth.

‍

Choosing between filter activities and SQL queries

‍

When a filter activity is enough

If your segmentation can be expressed as one or more conditions on fields in a single source data extension, a filter activity will usually do the job.

Examples include contacts in a given country, contacts created in the last 30 days, or contacts with a specific lifecycle stage.

Filter activities are easier to hand off because the logic is visible in the UI without parsing SQL.

‍

When you need a query activity

Once you have to combine data, you need SQL. Joining _Sent with _Open to find unengaged subscribers, deduping across multiple data extensions, or using window functions all require a query activity.

The same is true for anything that depends on data views like _Job, _Subscribers, or _Bounce, since filter activities cannot access them directly.

The honest rule of thumb: if you find yourself fighting the filter builder, stop and write the query. The activity that takes you ten minutes today will take the next person on the team three hours to reverse engineer.

‍

Refreshing audiences on a schedule

‍

Manual refresh and where it breaks

You can refresh a Filtered Data Extension or rerun a query manually from the UI. This is fine for one-off campaigns and a poor default for anything recurring.

Manual refreshes get skipped during holidays, after team changes, or whenever the person who built the audience is out of office. The audience still looks live in the UI, which is the part that bites you.

‍

Automating the refresh in Automation Studio

The standard pattern is to wrap the filter or query activity in an Automation Studio automation, schedule it ahead of the send, and let it run on its own.

A typical setup runs the audience build at 06:00, runs any dependent queries at 06:30, and the send itself at 08:00. The exact times do not matter; the sequence does.

Whenever possible, place the audience refresh and the send in the same automation. A separate automation that "usually finishes before the send" eventually does not.

For high-volume sends, add a small buffer between the last refresh activity and the send. A few extra minutes is cheap insurance against a long-running query that pushes past its window.

‍

Common pitfalls when building dynamic audiences

‍

Stale source data extensions

A dynamic audience is only as fresh as the data extension it sits on top of. If your source DE is updated by a weekly file import, your "live" audience is also weekly, regardless of how often you refresh the filter.

The fix is to walk the chain backwards: send, then audience DE, then source DE, then the import or query that populates the source.

‍

Joins across data views

Data views like _Sent and _Open hold only the last six months of tracking by default. A query that joins on engagement events looks correct in March and silently goes wrong in October when the rolling window cuts off the data you were counting on.

Treat any audience that depends on data views as having a freshness window, and document it next to the query.

‍

Counting subscribers instead of contacts

SFMC has subscriber keys and contact keys, and they are not always the same. An audience that counts SubscriberKey when the rest of the org keys on ContactKey will produce surprising numbers and even more surprising suppressions.

Pick one identifier per audience, write it into the audience definition, and treat any deviation as a bug.

‍

A practical workflow for a marketing team

‍

Define the audience in plain language first

Before opening Email Studio or Automation Studio, write the audience definition in one or two sentences. Something like "all contacts in France who opened any email in the last 90 days and have not unsubscribed."

If you cannot describe it in plain English, the SQL will not save you. Most weird audience behavior traces back to a plain-language definition that was never agreed on.

‍

Translate the definition into the right activity

Once the definition is written, pick the simplest tool that can express it. Single source and single condition points to a filter activity. Multiple sources or data views points to a query activity. Journey-driven entry points to a Journey Builder entry source on the resulting data extension.

Keep one source of truth per audience. Two filter activities that both claim to produce the "active French subscribers" audience will diverge within a quarter.

‍

Document the refresh cadence next to the audience

Every dynamic audience should have an owner, a refresh cadence, and a retirement date. Without those three, audiences accumulate and the org becomes harder to reason about every month.

A short README inside the audience folder is usually enough. The point is that the next person can rebuild the picture from the data extension alone.

‍

See QAiry in action

‍

The hardest part of dynamic audiences in SFMC is rarely the strategy. It is translating the strategy into the right activity, the right filter, the right join, without spending a week on it.

If you want to see how this looks when the SQL is generated from a plain-language prompt, the walkthrough at qairy.com/product-demos covers a full audience build, and qairy.com/try-it-free lets you run a prompt against a sample data set.