Dialog with data: asking Copilot questions about unified customer data

What it does

Dialog with data lets a business user type a question about the unified customer data — "how many customers aren't in the loyalty scheme but have spent over a thousand pounds in the last six months" — and get an answer back, along with the SQL Copilot generated to produce it. It sits on the Discovery page and it queries your own unified data, not a model's general knowledge.

Key facts

Preview. The docs are explicit that it isn't for production use and may have restricted functionality.
Path is Insights > Discovery. The page header reads "Discover insights about your customers in natural language", which is what to look for if the client's tenant has different navigation labels.
Prompts are capped at 2,000 characters, and the guidance is one question per prompt. Multi-part questions degrade badly.
Documented availability is the United States and Switzerland. Language and region coverage tracks the Copilot International Availability report rather than the product docs, so check that report per client rather than assuming.
Requires data to be imported and unified first. Activity data imported and unified as well is recommended — without activities you lose most of the behavioural questions, which is most of the interesting ones.
The user needs Admin or Contributor permissions. Viewers don't get it.
Gated by the same Enable Copilot features powered by Azure OpenAI consent setting (default On) as every other Copilot capability in the app.
Every answer exposes the underlying SQL query, so you can check how Copilot interpreted the question. This is the feature's saving grace and the thing to teach people to use.
Results come with an Explore further section of suggested follow-up questions and a "See more examples" control that regenerates suggestions.
Thumbs up/down feedback on results. There's also a per-prompt consent about sharing prompts for quality improvement, separate from the tenant-level data sharing consent.
Microsoft's own responsible AI FAQ flags the translation layer as a known limitation: results are converted from SQL back into natural language, and that conversion can introduce inaccuracy even when the SQL is right.

When to use / skip

This is the Copilot capability in Customer Insights - Data most likely to earn its place, because the SQL is visible. A data-literate analyst can ask a question, glance at the SQL, and know within seconds whether the answer means what they think it means. That's a genuinely faster loop than raising a request with the BI team.

Use it when the client has a real analyst population sitting downstream of the unified profile and a backlog of ad hoc "how many customers…" questions. Use it in a workshop to shake out data quality problems — nothing exposes bad unification faster than three plausible questions returning three implausible numbers.

Skip it where the audience won't read the SQL and won't caveat the number. A natural-language answer with no visible working, forwarded into a board pack, is a risk you don't want on your delivery. Skip it too where the data is thin: it can only answer questions the data supports, and an environment with profiles but no activities will disappoint everyone in the room. And it's preview, so don't scope it as a reporting replacement.

Configuration decisions

Whether Discovery is exposed to business users at all, or kept to the analyst group — permissions are the only real control, since there's no separate feature toggle for this capability alone.
How much activity data you unify before switching it on. The order matters: profiles-only environments give poor answers and burn the feature's credibility early.
Whether prompt sharing for quality improvement is acceptable to the client, and who communicates that to end users.
Whether answers from Discovery are allowed to be quoted externally, and what caveat wording accompanies them if so.
For non-US/Switzerland environments, whether cross-geography data flow consent will be granted — without it, this capability simply isn't available.
Whether you invest in friendlier table and column naming in the unified output specifically to improve Copilot's interpretation, since the docs advise referencing table and column names in prompts.

Gotchas

The generated SQL can be technically correct and semantically wrong. A question about "customers who bought recently" resolved against the wrong date column returns a confident number nobody can reproduce.
Answers depend entirely on unification having completed. Run Discovery against a half-refreshed environment and you'll get answers reflecting yesterday's data with no indication that's what happened.
Abbreviations and internal jargon do badly. Clients whose data uses in-house codes need to spell things out in the prompt, which undercuts the "just ask a question" pitch.
The prompt-level sharing consent and the tenant-level Allow data sharing for Copilot features setting are different things and get conflated in client conversations. The tenant one lives in the Power Platform admin center and is Off by default.
Contributor is a fairly generous role to hand out just to give someone Discovery access. Check what else that role opens up in the client's environment before using it as the access mechanism.
Feature availability is reported through the Copilot International Availability report rather than the product docs, so a "supported region" answer sourced from the product page alone can be out of date.

Consultant notes

Teach the SQL panel in the first five minutes of any training session. It is the difference between a tool people trust appropriately and one they trust blindly.
Demo it after unification is properly done, never before. A weak demo here poisons the client's view of Copilot across the whole product.
Tell the client this is preview and that the number it returns is a starting point for a question, not a reportable figure. Get that written down somewhere.
Push back on requests to embed Discovery answers into recurring reporting. If the question recurs, build a measure or a proper report — that's what measures are for.
Before go-live, run the client's ten most common ad hoc questions through it yourself and record which ones it gets wrong. Hand that list over as a known-limitations note; it saves a fortnight of support tickets.

Worth another look when this moves out of preview, or if the SQL verification panel changes shape.