Best Ways to Build Audiences in Salesforce Marketing Cloud

‍

Ask five SFMC practitioners how they build an audience and you will get five different answers.

Some reach for a Filtered Data Extension. Some open Automation Studio and write a query. Some are still maintaining an Audience Builder setup that predates half the team.

None of them are wrong, exactly. They are just optimising for different constraints.

‍

The trouble is that most teams pick a method once, early, and then never revisit it. The org grows, the data model gets messier, and the method that made sense for 40,000 contacts starts producing 25 minute queries and confused handovers.

Salesforce has also moved the goalposts. One of the four options below is on a retirement path, and another one Salesforce itself recommends you stop using past a certain scale.

‍

This post walks through the four realistic ways to build an audience in Marketing Cloud Engagement today, what each is actually good at, where each breaks, and how to pick between them without relearning the whole platform.

‍

What building an audience means in SFMC

‍

The audience is almost always a data extension

Whatever route you take, the output is the same shape: a data extension holding the contacts you intend to reach.

Email Studio sends to it. Journey Builder can use it as an entry source. Automation Studio refreshes it on a schedule.

So the real question is not what is an audience. It is which mechanism you use to decide who lands in that table, and how often that decision gets recomputed.

‍

Where the underlying data actually lives

Your source data sits in two very different places, and this is the split that determines which method works.

Sendable data extensions hold what you loaded: CRM attributes, purchase history, preference centre values, loyalty tiers.

System data views hold what SFMC recorded: _Sent, _Open, _Click, _Bounce, _Subscribers. These are not data extensions and you cannot browse them in the UI.

‍

That distinction matters more than anything else in this article. Any behavioural criterion (opened in the last 90 days, bounced twice, never clicked) lives in the data views, and only some of these methods can reach them.

‍

Filtered Data Extensions: the low-friction option

‍

What they do well

A Filtered Data Extension lets you narrow an existing data extension by its fields or measures, or by applying a data filter you have already defined.

It is point and click. No SQL, no Automation Studio, no query activity to schedule.

For criteria that live directly on the source table, this is the fastest path in the platform. Country equals France, loyalty tier equals Gold, opt-in flag is true: done in about ninety seconds.

‍

They are also self-documenting in a way SQL is not. A colleague can open the filter and read the logic without knowing the schema.

‍

Where they run out of road

The ceiling arrives quickly, and it arrives in three predictable ways.

• You cannot join. One source data extension only.
• Engagement criteria are out of reach unless someone has already pushed that data into the table.
• Deduplication, ranking, and any kind of aggregation are simply not expressible.

‍

The moment a brief says "purchased in the last six months but has not opened since", a Filtered Data Extension cannot answer it. You need to combine a purchase table with _Open, and that is a join.

‍

SQL Query Activities: where most real segmentation happens

‍

Why teams end up here

Salesforce describes the query activity as the way to retrieve and unify data across data extensions and system data views. That second half is the whole reason it exists.

It is the only native mechanism that reads the data views directly. Every engagement based audience, every suppression list built from bounce history, every reactivation segment goes through a query activity.

It is also the only one that can join, deduplicate with a window function, and rank.

‍

In practice this makes the query activity the default for anything a marketer would call interesting, which is exactly why so many SFMC teams end up with a queue in front of one or two SQL-literate people.

‍

The limits worth knowing before you scale

Query activities are not unbounded, and the published guidance is more conservative than most teams assume.

• A query activity times out at 30 minutes. That is a hard stop, not a warning.
• If a query consistently runs longer than 10 minutes, Salesforce recommends moving that work to a different tool such as Data Cloud.
• A query activity that fails 24 times consecutively is deactivated.

‍

Salesforce also recommends limiting a query's date range to about six months of data where you can, and narrowing scope as aggressively as the brief allows. On large orgs, an unbounded scan of _Open is the single most common cause of a run creeping toward the timeout.

‍

Audience Builder and the retirement question

‍

What Salesforce has announced

Audience Builder gave non-technical users a drag and drop way to assemble segments from attributes and behaviours, without writing SQL.

Salesforce announced its retirement in November 2024. Existing subscriptions are honoured until their end date, after which the application is no longer usable.

It is not switched off tomorrow, but it is not a destination either.

‍

What that means for your roadmap

If your org still runs on Audience Builder, the practical question is what absorbs that work when the subscription lapses.

In most cases the answer defaults to SQL query activities, which quietly moves segmentation from marketing back to whoever owns the queries. That is a staffing change disguised as a licensing change, and it is worth planning for early rather than discovering it a month out.

‍

Data Cloud and the warehouse route

‍

When Salesforce points you here

For unifying and segmenting genuinely large datasets, Salesforce's own recommendation is to use an internal data warehouse or Data Cloud rather than pushing the Marketing Cloud database harder.

Data Cloud segments can then be used inside Journey Builder, so the audience still arrives where your campaigns need it.

‍

The trade-off

This route solves the scale problem properly. It also adds a platform, a data model, a licence, and usually a second team.

For an org running 30 campaigns a month against a few million contacts, it is often the right long term answer and the wrong answer for this quarter.

‍

How to choose without relearning the platform

‍

Match the method to the question

A short rubric that holds up in most orgs:

• Criteria all on one table, no history involved: Filtered Data Extension.
• Anything touching engagement, joins, dedupe, or ranking: SQL query activity.
• Queries routinely over 10 minutes, or unification across many systems: Data Cloud or a warehouse.

‍

Most teams overuse the middle option because it is the only one that never says no. That is fine until the queue in front of it becomes the actual bottleneck in campaign delivery.

‍

Automation hygiene that applies to every method

Whichever route you take, a few Salesforce recommendations prevent the most common production failures.

• Sequence activities that read a data extension after the query that populates it, in a later step, never the same one.
• Do not run an import activity and a query activity against the same data extension in one automation. That creates contention in the data store.
• Stagger automations by five to fifteen minutes instead of clustering them on the hour.

‍

These are unglamorous, and they account for a surprising share of the "the audience was empty this morning" tickets.

‍

See QAiry in action

‍

The honest summary is that SFMC gives you one flexible method and several convenient ones, and the flexible one requires SQL. That is why segmentation queues form.

QAiry sits on the flexible path and removes the SQL requirement: you describe the audience in plain language and get a production-ready query against your own data extensions and data views. You can see how that works at qairy.com/product-demos, or try it on your own org at qairy.com/try-it-free.