The Death of Manual Segmentation
SFMC segmentation still runs on SQL and data views. See how Salesforce's own no-code segment canvas and Einstein tools are changing who can build an audience.
The Death of Manual Segmentation
For more than a decade, building an audience in Salesforce Marketing Cloud has meant one thing: writing SQL.
A marketer wants a list. Someone on a technical team opens a Query Activity, writes a query against a handful of data extensions, and runs it.
That workflow has barely changed since Automation Studio first shipped.
What has changed is how visible the cost has become.
Marketing teams wait days for lists that should take minutes. Technical teams juggle segmentation tickets alongside everything else already on their plate.
Neither side is doing anything wrong. The workflow itself was simply built for a smaller, slower era of campaign planning.
Salesforce itself is now building around this problem, not just documenting it. This post looks at what manual segmentation actually involves, what Salesforce is building to replace parts of it, and what changes once SQL stops being the only way in.
Why manual segmentation still runs on SQL
The Query Activity workflow
In Automation Studio, a SQL Query Activity retrieves data for reporting or for building an audience.
Salesforce's own training material walks through the same four building blocks every time:
SELECTto name the fieldsFROMto pick the sourceJOINto combine tablesWHEREto filter the result
Getting comfortable with join types (inner, left, right, full outer) is treated as a prerequisite, not an optional extra.
Once the query runs, the output has to land somewhere. The activity writes to a data extension, and the marketer chooses whether that extension is appended to, updated, or overwritten.
Every one of those choices matters for what happens downstream, since a journey or a send often assumes a specific structure in that output extension.
Where the friction actually lives
None of this is exotic SQL. It is joins and filters, the same patterns repeated with different criteria each time.
But repetition is exactly the problem. Every campaign brief becomes a new ticket, and every ticket needs someone who can write and test a query correctly.
Salesforce's own documentation warns against writing SELECT * queries, since pulling every column from a large data extension can slow a job enough to hit its 30-minute timeout.
That is a small detail with a large implication: even people who already know SQL have to write it carefully to avoid breaking a job.
Multiply that carefulness across dozens of campaigns a month, and the query queue becomes a quiet bottleneck long before anyone calls it one.
The system tables behind every segment
What data views give you
Underneath most segmentation queries sit data views: system-generated tables like _Bounce, _Click, _Open, and _Complaint that hold engagement history automatically.
They exist so marketers do not have to build their own tracking tables from scratch.
Salesforce documents more than twenty of these views across email, SMS, journeys, automations, and social forwards.
What they don't give you
Data views are fixed. Their schema cannot be changed, and a missing column cannot be added later.
Anyone querying them has to already know which view holds which event, and how to join it back to a SubscriberKey or contact ID.
That knowledge is exactly what turns a simple-sounding audience request into a task that only one specific person on the team can complete.
It also means onboarding a new team member takes longer than it should, since the data views themselves rarely come with much documentation beyond Salesforce's own reference pages.
Salesforce's own answer: segmentation without SQL
The segment canvas in Data Cloud and Marketing Cloud Next
Marketing Cloud Next runs on the same segmentation interface as Data Cloud. Instead of a query, a segment is defined as a set of filtering rules applied to a database.
The workflow starts from the total audience, then narrows it: drag an attribute from a library onto the canvas, decide whether it belongs on the Include or Exclude side, and group related conditions together for more complex logic.
No query editor is involved at any point in that process.
Limits worth knowing
The canvas is not unlimited. Salesforce caps segments at 50 filters on the Include tab and 50 on the Exclude tab.
Refresh timing is a deliberate choice too: a team can set a segment not to refresh at all, refresh on a standard 12 or 24-hour cycle, or refresh rapidly every 1 to 4 hours.
Campaign segments also have to run against the default data space and the Unified Individual object, which is a constraint worth knowing before planning a migration.
None of this replaces every use of SQL inside SFMC. It shows that Salesforce now treats a visual, filter-based builder as a first-class way to define an audience, not a simplified toy version of the real thing.
Where Einstein fits into segmentation today
Einstein Engagement Scoring
For Marketing Cloud Engagement, Einstein Engagement Scoring uses machine learning to predict how likely a contact is to engage with email or mobile push.
Salesforce documents minimum data requirements for the scores to be reliable: at least 7 days of history, 28 days recommended, and 90 days for the strongest results.
The scoring itself falls under what Salesforce calls Smart Segmentation, one of three Einstein categories that also cover send-time optimization and content selection.
Co-creating a segment with Einstein
On the Data Cloud side, Salesforce has also introduced a co-create option that lets a marketer describe an audience and have Einstein assist in building the corresponding segment.
It points in the same direction QAiry was built around from the start: describe the audience you want in plain language, and let the system produce the technical definition behind it.
The difference is where each approach lives. Einstein's co-create option sits inside Data Cloud and Marketing Cloud Next, while QAiry is built for teams running Marketing Cloud Engagement today, on the SQL and data extension model already described above.
What actually changes when SQL leaves the workflow
Speed
A query that used to sit in a ticket queue for two or three days can become a conversation that takes minutes.
That difference is not marginal. For a flash sale or a reactivation push tied to a specific event, minutes versus days decides whether the audience is still relevant when the send goes out.
Who gets to ask the question
The bigger shift is about who can define an audience at all.
When the only interface to segmentation is SQL, only people who write SQL can experiment with it. When the interface is a filter canvas or a plain-language request, the marketer closest to the campaign can test an idea without waiting on someone else's calendar.
That does not remove the technical team from the picture. It changes what they spend their time reviewing, from writing every query to checking the ones a marketer already drafted.
What doesn't change
Data governance does not disappear just because the interface got friendlier. Someone still has to decide which fields are safe to segment on, and which data extension is the source of truth.
SQL is not disappearing from SFMC either. Complex, multi-step data preparation, the kind that feeds a segment rather than defines one, will likely stay query-based for a long time.
What changes is where that SQL sits in the process, not whether it exists at all.
See QAiry in action
The tools are changing faster than the habits built around them. Most SFMC teams still route every audience request through the same query queue that existed five years ago.
QAiry sits inside that gap: a marketer describes an audience in plain language, like "contacts who opened in the last 30 days but haven't clicked," and QAiry generates the SQL and builds the audience in SFMC directly. See how it works at qairy.com/product-demos, or start a no-cost trial at qairy.com/try-it-free.
