Query assist for segment building

What it does

You describe the audience you want in ordinary words — "people who attended the Contoso coffee tasting and opened an email recently" — and Copilot proposes the matching segment logic against your data model. It fills the segment builder with conditions you then check and edit. It is a shortcut past knowing which table and which relationship holds the thing you are after.

Key facts

Lives in Audience > Segments. You name the segment and choose the audience type — Contact or Lead — before describing it. The audience type frames what Copilot can propose.
Accepts both conversational phrasing and more formal query language; you do not need to match a syntax.
Suggestions appear in a Query assist panel on the right. You apply one with Use, which drops it into the builder as conditions.
Running a second search appends the result as a new group rather than replacing what is there, so you can build a multi-part segment through several passes.
There is a See more examples option when the first suggestion misses.
Thumbs up and thumbs down feedback on each suggestion feeds the model. Worth telling users, because they otherwise ignore it.
Gated by the Global opt-in consent feature switch under Settings > Overview > Feature switches, the same switch that governs the other Copilot text features in the app.
The documentation page does not state a preview or GA badge, a region list, or a language list. Check the tenant and the Copilot international availability report rather than assuming parity with the US-only features.
The output is ordinary segment logic. Once applied there is no residual dependency on Copilot — the segment behaves exactly like a hand-built one.
A related but separate capability lets you type natural language into an Attribute branch inside a journey, reached with the lightbulb icon in the attribute pane. Same idea, different place in the product.

When to use / skip

This is the Copilot feature in the app with the clearest payback, because it attacks a real skills gap. Marketers know the audience they want and do not know the Dataverse schema; segment building is where they stall and where they raise tickets. Turning it on shortens that loop and reduces the "can you build me a segment" queue landing on the CRM team.

Where it disappoints is complexity. Simple attribute filters and single-hop relationships come out well. Multi-condition segments with nested groups, date arithmetic and exclusions are where it starts guessing, and the user cannot tell a good guess from a bad one. So treat it as an accelerator for straightforward segments and a scaffold for hard ones — never as a replacement for someone who understands the data model reviewing the result.

Skip promoting it heavily on a client with a heavily customised or badly named schema. If the tables are called things like new_entity3 with no display names, Copilot has nothing to reason over and the suggestions are noise.

Configuration decisions

Global opt-in consent on or off — a single decision shared with content ideas and content rewrite, so handle it once.
Whether segment creation stays with a central team or opens up to marketers now that the schema barrier is lower. That is a governance decision with real consequences for segment sprawl.
Whether custom tables and fields are given sensible display names and descriptions. This directly determines whether query assist is useful on custom data.
Whether generated segments are reviewed before use in a live journey, and by whom.
Naming and lifecycle conventions for segments, because usage volume will go up once this is available.

Gotchas

A confident-looking suggestion can be subtly wrong — the right table, the wrong relationship direction, or a date window that does not mean what the user thinks. Nothing flags it. Always look at the resulting member count against expectation.
Successive searches add groups rather than refining. Users expecting a conversational refinement end up with a segment full of stacked groups joined in ways they did not intend.
Choosing Contact when the client's marketing actually runs on Lead (or the reverse) produces suggestions that look plausible and target the wrong audience entirely.
The consent switch is shared. Disabling it for a segment-related concern silently removes the copy generation features as well.
Custom fields without display names are effectively invisible to it, which makes the feature look broken on exactly the projects that most need it.
Availability by region and language is not stated on the page. Do not commit to it in a scope document without verifying it in the target tenant.

Consultant notes

Demo it against the client's own schema, not a demo tenant. The whole point is that it navigates their data model, and a generic demo proves nothing.
Use it as the argument for a schema tidy-up. "Give your custom fields proper display names and this works" is a much easier sell than data hygiene for its own sake.
Train users to check the member count and the generated conditions every time. Make that the habit, not an optional extra.
Tell the client the thumbs up and down are not decoration — feedback is the only lever they have on suggestion quality.
Before go-live, verify the switch state in production and confirm at least a handful of representative segment descriptions produce sane logic. Ten minutes of testing here prevents a fortnight of complaints.

Worth revisiting when Microsoft publishes a clear preview or GA status and a region list for this one — the docs are notably quiet on both.