The Future of Audience Creation in SFMC

‍

Audience creation in Salesforce Marketing Cloud has always rewarded patience. You define the logic, you write the query, you wait for it to run, and then you check the counts.

That model built a generation of marketing operations teams. It is also starting to change.

‍

The shift is not about replacing SFMC. Data extensions, send relationships, and data views are all staying exactly where they are. What is changing is the interface between a marketer's intent and the audience that lands in a campaign.

‍

This post looks at how audiences are built in SFMC today, where the friction actually lives, and how AI is changing the front of that workflow without touching the mechanics underneath.

‍

How audience creation works in SFMC today

‍

Data extensions and the subscriber key

Most audiences in SFMC live in data extensions. A sendable data extension carries a send relationship and maps each row to a subscriber through the SubscriberKey.

Salesforce recommends storing the SubscriberKey as text, which keeps that relationship stable as data flows in from different sources.

‍

Nonsendable data extensions hold reference data instead: order tables, product catalogs, or anything you use to personalize a message rather than address it.

The distinction is not academic. A segment is only useful if the final table it writes to is sendable, so the plumbing decides whether an audience can actually ship.

‍

Where SQL and data views come in

To build a segment, most teams write a SQL query activity in Automation Studio. The query reads from data extensions or from system data views, and it writes its result into a target data extension.

‍

Data views expose engagement history that never sits in an ordinary data extension. Tables like _Sent, _Open, _Click, and _Bounce let you filter on behavior instead of attributes alone.

‍

That is how a request like contacts who opened in the last 30 days but did not click turns into a real audience. The behavior lives in the data views, and the join brings it together with the profile.

‍

Once the query is written, it can be scheduled in Automation Studio so the audience refreshes on its own. That scheduling is powerful, but it assumes the query was correct in the first place, which is where the real work sits.

‍

Why the current model slows teams down

‍

The dependency on technical skills

The logic above is not hard to describe. It is hard to write correctly.

A marketer knows the audience they want. Turning that into indexed joins across data views is a different skill, and in most orgs it lives with a small number of people.

‍

So the request goes into a queue. The marketer waits, the specialist context switches away from deeper work, and a campaign that was ready as an idea sits idle in practice.

This is rarely anyone's fault. It is just the shape of the tool.

‍

The cost of every small change

The queue is hardest on iteration. Shifting a date window, adding one exclusion, or splitting a segment in two each means another round trip.

‍

Every change is small on its own. Across a quarter, the accumulated waiting becomes one of the quieter and larger costs in a marketing operation.

It also discourages experiments, because each test carries a coordination tax that a quick idea rarely feels worth paying.

‍

What is changing: AI enters the workflow

‍

Natural language segment creation

Salesforce has begun moving audience creation toward natural language. Einstein segment creation in Data Cloud lets you describe the audience you want in plain words and generates the segment definition for you.

‍

Newer Marketing Cloud experiences extend the same idea, offering AI assisted segment building in place of a blank query editor.

The intent across these features is consistent: let the marketer state the goal in words, and let the system handle the structure.

‍

Einstein and Data Cloud signals

AI does more than translate a sentence into a filter. Einstein engagement scoring and related models can rank contacts by their likelihood to open or click, which feeds richer segments than static attributes can express.

‍

Paired with Data Cloud, this points toward audiences that are described once and refreshed continuously, rather than rebuilt by hand every time the campaign runs.

The description becomes the durable artifact, and the underlying data does the updating.

‍

It is worth being clear about the limits. These features shine when the underlying data is well organized, and they still ask a person to review what the model proposes before it drives a send.

‍

What stays the same underneath

‍

Sendable data extensions still matter

None of this removes the plumbing. Whatever describes an audience, the campaign still needs a sendable data extension with a valid SubscriberKey before a single message goes out.

‍

An AI generated segment that cannot be sent is a draft, not an audience. The last mile is still SFMC, and the send relationship still has to be right.

‍

Data quality and indexing still decide performance

SQL in SFMC performs best when the fields used in JOIN, WHERE, GROUP BY, and ORDER BY are indexed. That guidance does not disappear when a machine writes the query.

‍

If anything it matters more, because generated logic runs against the same tables, the same volumes, and the same processing limits as anything written by hand.

Clean keys and sensible indexes are still what separate a query that finishes from one that times out.

‍

How natural language segmentation maps to SQL

‍

From a sentence to a query

The useful way to think about this is translation. A marketer writes active buyers in France who have not opened in 60 days, and the system produces the SQL that expresses it.

‍

Behind the sentence sits a familiar shape: a join between a purchase table and _Open, a date filter built with GETDATE(), and a write into a sendable data extension keyed on SubscriberKey.

The words change, but the structure underneath is exactly what a specialist would have written.

‍

Keeping queries production ready

A generated query is only valuable if it is safe to run. Production ready means the right indexed fields, date logic that behaves at the boundaries, and a result that respects the send relationship.

‍

The goal is not a query that merely looks correct in a preview. It is a query a team can schedule, rerun, and trust week after week.

That standard is what separates a helpful draft from something a marketer can actually put into an automation.

‍

Reviewing generated SQL is also a good habit for another reason. It keeps the marketing team fluent in what their own audiences mean, so the logic stays understood rather than hidden inside a black box.

‍

What this changes day to day

‍

For most teams the headline is speed. The marketer describes the audience, reviews the logic, and moves on without opening a ticket.

The specialist is freed for the work that genuinely needs their judgment, like data modeling and thorny edge cases.

‍

See QAiry in action

‍

QAiry sits at exactly this layer. You describe the audience you want in plain language, and it generates production ready SQL for SFMC that respects your data extensions and data views.

‍

See how it works at qairy.com/product-demos, or build your first audience at qairy.com/try-it-free.