What Happens When Marketers Stop Writing SQL

‍

Most conversations about AI in Salesforce Marketing Cloud focus on what gets removed. No more query editor, no more waiting on a technical colleague, no more debugging a join at 6pm before a send.

That framing is incomplete. Removing SQL from a marketer's daily workflow does not simply delete a task. It moves the work somewhere else and changes who is accountable for what.

‍

The interesting question is not whether marketers can stop writing SQL. In most enterprise orgs, a large share of them never wrote it in the first place. The question is what the operating model looks like on the other side.

‍

This post walks through what actually changes when natural language becomes the primary way audiences get built in SFMC: the skills that stop mattering, the ones that start mattering more, and the guardrails that have to move with the work.

‍

What SQL was really doing in the workflow

‍

It was a translation layer, not a skill

For most marketing teams, SQL in SFMC was never the point. It was the only available way to express an audience definition that the platform could execute.

A marketer thinks in terms of "people who opened something in the last 60 days but have not clicked since spring." The platform thinks in terms of _Open, _Click, SubscriberKey, and a date function.

SQL was the bridge between those two vocabularies. It was a translation cost, not a source of value.

‍

It was also a gatekeeping mechanism

Because the translation cost was high, it concentrated in a small number of people. In a large org that is usually two or three individuals who know where the data lives and which data extension is actually current.

That concentration had one genuine benefit: it created a review step. Every audience passed through someone who understood the schema.

It also created the bottleneck everyone complains about. Both things were true at once, which is why removing SQL is not a purely additive change.

‍

The constraints do not disappear when the syntax does

‍

Platform limits stay exactly where they were

SFMC's SQL Query Activity is based on SQL Server 2016 capabilities but does not correspond to them precisely. It supports SELECT statements against data extensions and data views in the account or its parent account, and nothing else. No INSERT, no UPDATE, no SELECT INTO.

Queries time out after 30 minutes. Salesforce's own guidance is that if a query consistently runs longer than ten minutes, you should be transforming that data somewhere else instead.

A query that combines a join with SELECT * is not permitted at all.

‍

Data retention still bounds what you can ask

System data views hold roughly six months of subscriber and journey engagement history, queryable through Automation Studio. Open and click data both sit inside that window.

This matters more than it sounds. "Contacts who have never engaged" and "contacts who have not engaged in the queryable window" are different populations, and only one of them is something SFMC can answer.

An AI layer that generates SQL inherits every one of these boundaries. It does not negotiate them away.

‍

What actually changes day to day

‍

The visible change is speed. An audience that took a ticket, a queue, and two days now takes a sentence and a review.

The less visible change is that iteration becomes cheap enough to be worth doing. When a segment costs two days, you ship the first version. When it costs two minutes, you check the count, notice it is smaller than expected, and fix the assumption behind it.

‍

That second effect is the one that shows up in campaign performance. Most segmentation errors in SFMC are not syntax errors. They are reasonable assumptions that nobody had the budget to test.

The third change is quieter still. Requests that were never made because they were not worth the ticket start getting made.

‍

The skills that gain value

‍

Precision in stating intent

Natural language moves the difficulty from syntax to specification. Customers who bought recently is not an audience definition. It has no time window, no product scope, and no statement about whether a return counts.

The marketers who get the most out of a conversational layer are the ones who were already rigorous about defining audiences. The prompt just makes that rigour visible.

‍

Reading a query well enough to reject it

You do not need to write GETDATE() from memory. You do need to look at a generated query and notice that it joined on email address instead of SubscriberKey, or that the date filter is inclusive at the wrong end.

This is a real shift in the skill profile: from production to review. Reading is a much easier skill to teach across a team than authoring, which is why it scales where SQL never did.

‍

Knowing your own data model

No natural language layer can tell you that Purchases_Master stopped being updated in March and everyone quietly moved to a new extension.

That knowledge is organisational, not technical. It becomes more valuable, not less, once the syntax barrier is gone.

It also becomes worth writing down. When only three people built audiences, the data model lived in their heads and that was survivable. When thirty people build audiences, it has to live in documentation.

‍

Where governance has to move

‍

The old review step vanishes by default

When SQL was scarce, review happened automatically because everything routed through the same two people. Take that away and audiences can go from idea to send with no second pair of eyes.

Teams that handle this well replace the implicit checkpoint with an explicit one. Usually that means a count sanity check and a named approver for anything above a volume threshold.

‍

Suppression logic deserves stricter handling

Inclusion errors are visible: you send to the wrong people and someone notices. Exclusion errors are silent, because nobody complains about an email they did not receive.

Global suppression, consent, and legal exclusion lists should stay as reviewed, reusable components rather than being regenerated conversationally for each campaign.

‍

Auditability becomes a requirement, not a nice-to-have

If an audience was defined in a sentence, that sentence needs to be stored alongside the SQL it produced. Six months later, "why did this campaign target these 40,000 people" has to have an answer.

Salesforce's own approach with Marketing Cloud Growth points the same direction: natural language prompts generate segments, with the Einstein Trust Layer handling data governance around the model.

‍

Who ends up better off

‍

The technical team, more than expected

The common fear is that removing SQL removes the reason for the technical team to exist. In practice the opposite tends to happen.

Those people stop spending their week on routine segment tickets and start working on the data model, the schema, and the automations that make good segmentation possible. That work was always more valuable and always got deprioritised.

‍

The teams that were previously stuck

Regional and smaller business units feel this most. They were the ones whose requests sat at the bottom of a shared queue behind whichever market had the biggest budget.

The change here is not that they go faster. It is that their campaign ambition stops being capped by someone else's capacity.

‍

See QAiry in action

‍

QAiry generates production-ready SFMC SQL from a plain-language description of the audience you want, so the review step stays with the marketer who understands the campaign.

If you want to see how that works against your own data model, take a look at qairy.com/product-demos or start with qairy.com/try-it-free.