What's New in QAiry 3.1
Smarter metadata understanding, four types of data extension, Manual Edit as a builder, SQL as an entry point, and Waterfall refreshes. What shipped in 3.1.
What's New in QAiry 3.1
QAiry 3.1 is out.
The short version: the assistant understands your SFMC metadata better, it reaches more of your data extensions, and it no longer assumes that chatting is the only way you want to work.
There is also a new automation model for refreshing dependent data extensions in the right order.
Together these are the largest set of changes since the product launched.
This post walks through what shipped, and what each change is actually solving inside a Marketing Cloud org.
One workspace, three ways to build
Chat, Manual Edit and SQL are now peers
Earlier versions treated the conversation as the front door. You described an audience, QAiry drafted the SQL, and Manual Edit was where you tidied up afterwards.
In 3.1, all three tabs are entry points.
You can open a new audience straight in Manual Edit and build the logic step by step. You can open the SQL tab, paste a query you already trust, and carry on from there.
The audience object itself has not changed, so all three tabs operate on the same query and the same output.
Why a single entry point was a problem
SFMC teams are rarely uniform. A campaign manager wants to describe the audience. A developer wants to see the join. Both are working on the same brief.
Forcing everyone through the same door meant one of them was always working against the tool.
The fix was not to add a mode. It was to stop treating one of them as the default.
Chat understands your data model better
Answers grounded in your environment
The biggest change in 3.1 is not a new button. It is that QAiry reads your Data Extensions, fields and relationships more accurately before it writes anything.
Requests are interpreted against your business unit rather than a generic SFMC schema, so the SQL that comes back references tables and columns that actually exist.
Relationships matter as much as tables here. Knowing that Orders joins to Clients one-to-many, and that Payments sits one-to-one behind it, is the difference between a correct audience and an inflated one.
QAiry also tracks what you are working toward across a conversation and suggests the next step, instead of treating each message as an isolated request.
Connecting a data extension without leaving the chat
Previously, if QAiry needed a table you had not connected, the conversation stopped while you went to configure it.
Now you can search, select and connect the missing data extension from inside the conversation, then pick up where you left off.
It is a small change that removes one of the most common interruptions in an audience build.
The alternative was always a context switch, and context switches are where half-finished audiences get abandoned.
More of your data extensions are reachable
Four types, not one
3.1 widens what QAiry can pull into an audience:
- Data Extensions connected to your business unit.
- Shared Data Extensions, so you can work across business units.
- Synchronized Data Extensions, carrying Salesforce CRM data.
- Salesforce Data Extensions generated by the CRM integration.
What this solves in an Enterprise org
Marketing Cloud Connect and Synchronized Data Sources pull records from Salesforce CRM objects into data extensions. In an Enterprise 2.0 account, those extensions sit at the top level of the tenant by default.
Salesforce's own guidance for getting that data down to a business unit is to run a query activity that moves it into a new data extension, then share that extension.
That is a pipeline to build and maintain before anyone can segment on a CRM field.
Reading those sources directly removes a step that existed only to shuttle data around.
Worth remembering: Salesforce recommends synchronizing only the fields you need, and suggests around 20 fields per object as a performance guideline. Reaching more sources does not change that advice.
Manual Edit is now a builder
Five steps, in order
Manual Edit used to be an editing surface. In 3.1 it is a structured builder that walks an audience from sources to output.
- Select the connected data extensions you want to use.
- Choose the join logic between them.
- Add the filters a contact must satisfy.
- Apply exclusions.
- Review and organise the output fields.
The order is deliberate. Exclusions come after filters because suppression lists are where audiences most often go quietly wrong.
Build first, ask later
Because Manual Edit is now an entry point, you can assemble the whole thing visually and never open Chat.
Or build the skeleton by hand and hand the assistant the part you would rather not write. Both modes act on the same audience, so moving between them costs nothing.
Starting from SQL you already have
Paste a query and keep going
Most SFMC teams have a folder of queries that already work. 3.1 lets you open the SQL tab, paste one in, validate it, and keep refining the audience inside QAiry.
Nothing is rewritten behind your back. The query stays yours, and you can revert to the saved version at any point.
This matters more than it sounds. A query that has been reviewed once and runs reliably is an asset, and most teams are reluctant to hand it to anything that might quietly reshape it.
Moving between the tabs
There is no prescribed path. The right one is whichever fits the request in front of you.
Start in SQL, move to Manual Edit to adjust the exclusions visually, then ask Chat to extend it.
Or start in Chat and drop into SQL to check the join before you run anything.
Waterfall automation for dependent refreshes
Why refresh order is fragile in Automation Studio
Automation Studio runs activities in the step sequence you arrange, and you can place several activities in a single step.
That flexibility is also where teams get caught. Salesforce is explicit that an activity which queries or writes to a data extension has to sit after the query that populates it, and not in the same step, or it returns no results.
A long chain of dependent audiences turns into a sequencing puzzle, usually solved with wait activities and generous time buffers.
Those buffers are guesses. When data volumes grow, the guess stops holding.
Chaining instead of timing
Waterfall chains dependent data extension refreshes so that each step starts only once the previous one has finished.
A typical chain: build the base audience, enrich it with profile and behavioural data, apply suppression rules, then publish the final audience.
Each stage waits on the stage before it rather than on a clock, which takes the timeout pressure off long refresh chains.
The same refreshes are available over the API, so a chain can be triggered from outside Automation Studio entirely.
See QAiry in action
3.1 is live for existing installs, and the new builder is the fastest part to judge for yourself.
The walkthroughs at qairy.com/product-demos show the three tabs and a Waterfall chain running against a real org, and you can install it against your own business unit at qairy.com/try-it-free.
