Power BI Q&A - Getting Natural Language Questions to Actually Work
Every few months a client asks us some version of the same thing: "Can our managers just type a question and get the answer from Power BI?" They've seen a demo, usually involving a salesperson typing "total sales by region last quarter" and a perfect bar chart appearing.
The honest answer is yes, sort of, and it depends almost entirely on how well your data model is set up. Power BI has had this capability for years through a feature called Q&A. This post covers what Q&A is, how to get it behaving, and where it sits now that Copilot is the thing everyone wants to talk about.
What Q&A is
Q&A is Power BI's natural language query feature. A user types a question in plain English, Power BI parses the words, maps them to tables, columns and measures in the semantic model, and returns a visual as the answer.
It shows up in a few places:
- The Q&A visual in Power BI Desktop and in reports, which you add to a page like any other visual
- The Q&A box at the top of dashboards in the Power BI service
- Pinned Q&A answers, where you ask a question on a dashboard and pin the resulting visual as a tile
Microsoft's Q&A documentation covers the full feature set. What I want to focus on is the gap between "it's switched on" and "people use it".
Why Q&A gives bad answers
The first time most teams try Q&A on a real model, the results are underwhelming. Someone types "revenue by customer last month" and gets a table of something that isn't quite revenue, grouped by a column called CUST_ID_FK, with no date filter applied.
That's not Q&A being stupid. It's Q&A being literal. It only knows what your model tells it. If your measure is called Sum_Amt_Inc_GST_v2, Q&A has no idea that's what people mean by "revenue". If you've got three date columns and no proper date table, it'll guess at which one "last month" refers to.
In our experience the quality of Q&A answers correlates almost perfectly with the quality of the semantic model. Models built with a clean star schema, friendly names and a marked date table get good answers. Models that were dumped straight from a source system get rubbish.
Setting it up properly
Here's the process we follow when a client wants Q&A to be usable rather than a party trick.
1. Rename everything in business language. Tables, columns, measures. FactSalesLine becomes Sales. Amt_Net becomes Net Revenue. This is the single biggest improvement you can make, and it helps human report users as much as Q&A.
2. Hide what people shouldn't ask about. Surrogate keys, technical columns, staging fields. Hidden fields are excluded from Q&A by default, which cuts down on confused matches.
3. Add synonyms. In the model view in Power BI Desktop, every field has a synonyms property. Your finance team says "revenue", your sales team says "bookings", and your CEO says "top line". Add all three as synonyms on the same measure. This is tedious work, but it's where the quality jump happens.
4. Mark a date table. Q&A handles time phrases like "last quarter", "this year" and "in March" much better when there's a properly marked date table. If you don't have one, build one. We cover this in our date table design guide.
5. Use the Q&A setup tools. In Desktop, the Q&A setup area lets you review questions users have asked, see which terms Q&A didn't understand, and teach it what those terms mean. "Teach Q&A" lets you define something like "big customers" as customers with revenue over a certain amount. This is the best part of the feature and almost nobody uses it.
6. Add suggested questions. You can configure a set of starter questions that appear in the Q&A visual. These matter more than you'd think. A blank text box intimidates people. Six good example questions show them what's possible and nudge them toward phrasing that works.
7. Review the question log after go-live. Once real users start asking things, the list of questions Q&A couldn't answer is gold. Check it weekly for the first month and add synonyms or teach terms based on what you see.
What we've seen work
The most successful Q&A rollouts we've been part of share a few things in common.
The audience is narrow. A sales team asking questions about one sales model works well. "The whole company asking anything about anything" does not. Q&A works against a single semantic model at a time, so scope matters.
Someone owns it. One person, usually a BI analyst, checks the question log and keeps adding synonyms. Without that, the feature slowly rots as terminology changes.
It's positioned as a quick lookup, not analysis. "What were Brisbane sales last week?" is a great Q&A question. "Why did margins drop in Q3?" isn't something Q&A can answer, and setting that expectation up front saves disappointment.
We had a wholesale distribution client whose regional managers used to email the BI team for one-off numbers several times a day. After a few weeks of synonym work and suggested questions on a Q&A visual embedded in their main report, those emails dropped to a trickle. Nothing clever, just a well-named model and a feature that already existed.
The honest limitations
Q&A has real constraints you should know about before you promise it to anyone.
Language support is mainly English. If you've got users who want to ask in other languages, check current support before committing.
It struggles with complex questions. Multi-step logic, comparisons across unrelated tables, and anything involving "why" are beyond it. It's a query tool, not a reasoning tool.
Some data source configurations limit it. Q&A works with import and DirectQuery models, but there are restrictions depending on the connection type and model features. Check the documentation against your setup before planning a rollout.
Microsoft's attention has moved to Copilot. This is the big one. Microsoft has been steering natural language querying toward Copilot in Power BI and has announced plans to retire the Q&A experiences. Check the current timeline on Microsoft Learn before you invest heavily in Q&A-specific configuration like custom teach-Q&A terms.
Q&A versus Copilot
So should you bother with Q&A at all?
Here's my view. The work you do to make Q&A good is almost exactly the work you need to do to make Copilot good. Business-friendly names, synonyms, hidden technical fields, a proper date table, clear measure descriptions. Copilot reads the same model metadata and benefits from the same clean-up. Microsoft has even pointed people toward linguistic modelling and the "prep data for AI" tooling as the way to improve Copilot answers.
So I'd frame it this way:
- If you already have Q&A in use and people like it, keep it running while you plan the move to Copilot.
- If you're starting fresh, put the effort into model hygiene and AI-ready metadata rather than Q&A-specific features. That work carries forward.
- Don't spend days building custom teach-Q&A definitions for a feature with a limited future.
Copilot comes with its own considerations: it needs paid Fabric capacity, the answers are less deterministic than Q&A, and you'll want to think carefully about which models are exposed to it. We've written about using Copilot for DAX queries in Power BI if you want more on that side.
Where to start
If you want natural language questions working on your Power BI data, start with the model, not the feature. Pick one well-used semantic model, rename and hide fields properly, add synonyms for the twenty terms people use most, and mark your date table. Then try Q&A or Copilot against it and see how far you get.
Most organisations we talk to are surprised how much of the "AI" improvement comes from that unglamorous groundwork. If you'd like help getting a model into shape for natural language querying, our Power BI consultants do this regularly, and if you're thinking bigger about AI across your reporting, have a look at our Microsoft Fabric consulting work.