"Dave: Open the pod bay doors, HAL.
HAL: I’m sorry, Dave. I’m afraid I can’t do that.
Dave: What’s the problem?
HAL: I think you know what the problem is just as well as I do."
— Arthur C. Clarke & Stanley Kubrick, 2001: A Space Odyssey (1968)
(2025-Nov-24) Having a real conversation with Power BI is not a novel idea. Its ‘Q&A’ feature has been available for the past 10 years, allowing users to type questions in natural language and attempt to retrieve data-driven results and visuals from existing datasets. This feature was first introduced back in 2013 and gradually improved over time, becoming a solid platform for a broader audience to ask questions, essentially having one-sided conversations with Power BI. Don’t worry if Power BI didn’t talk back; the goal was just to get answers from your data.
Photo by Pavel Danilyuk: https://www.pexels.com/photo/a-robot-holding-a-cup-8439093/
Other conversational tools for visuals were also available in Power BI back in the day. Around the same time, a company called Narrative Science introduced a tool that did the reverse: it used your Power BI semantic data model to generate natural language explanations of your data. In a sense, this completed the conversation cycle, you could submit one-sided questions to Q&A and then rely on the Narrative Science component to communicate the results back to you in plain English. Later, when Narrative Science was acquired by Salesforce, Microsoft introduced its own sibling feature called ‘Smart Narratives.’
Nowadays, when you try to use this Power BI built-in visual component, you’re given a choice to use either a Custom or Copilot-based engine to provide those ‘smart’ narratives back to the end users. That would be my main focus today, to share my own experience of using Copilot with Power BI (or the Fabric data platform). Not in the way of providing instructions on how to use it, as Microsoft has provided really good intro and in-depth documentation. I felt that there was something in the Copilot-based analytics in Power BI that a good data professional would notice too.
But before I do, let me share how it all works in Power BI. First, there is nothing magical about the Copilot AI assistant: it’s a simple, or not-so-simple, Large Language Model (LLM) based tool that now not only provides smart data results or language narratives, but can also create new report artifacts or adjust content by adding new elements or changing existing ones in your reports and dashboards.
Copilot in Power BI works by taking user input from either Power BI Desktop or the Power BI Service and routing it through Fabric capacity, which acts as a proxy layer. This ensures that both desktop and service experiences leverage the same infrastructure for processing requests. Once the input reaches Fabric, it is sent to the Azure OpenAI service, where GPT-like models interpret the request and generate a response. The processed output is then returned through Fabric back to the user, enabling natural language-driven insights and report generation within Power BI.
Yes, you heard me right: Copilot in Power BI Desktop still requires Fabric capacity to work; you won’t be able to use it otherwise. I don’t think this will change, but it’s mainly driven by Microsoft’s desire to help users stop thinking of Power BI as a standalone product and instead see it as part of the Fabric platform, or, to put it simply, to teach you that "we create and maintain all our reporting and analytics in Fabric."
Before Copilot, Power BI already tried to ‘talk’ to users through Q&A, Quick Insights, and Smart Narrative. But those were single-shot interactions. Copilot turns that into an actual multi-turn conversation with your data and your report.
When you ask Copilot about your report calculations, it can provide a helpful overview of what’s happening behind the scenes. Since these explanations are generalized, you might see words like ‘usually’ or ‘typically’ a lot. Also, the accuracy of Copilot’s insights depends a lot on how you phrase your questions. Including context, specifying what you want to achieve, and noting relevant filters or columns can make a significant difference. In fact, the clearer your prompt, the more precise and useful the response will be. And, just for fun or not fun, some Microsoft folks have even suggested including ‘please’ and ‘thank you’ when interacting with Copilot. They really did mention this!
Here’s the big and interesting part: your experience with Copilot is still limited to your existing semantic data model. Currently, Copilot won’t help you add or remove tables or change relationships between them, you’ll have to handle that yourself. Of course, this may change in the future.
But, with this, there are several things that you can adjust in your semantic model to significantly improve your interactions with Copilot, and my main significance mainly remains in the data quality of the returned results.
Renaming Columns, Tables, Measures. You won’t believe it, or maybe you will, but simply changing a column called CustID to Customer ID means Copilot now understands when you ask, ‘Show me total sales by Customer ID.’ Rename a table from FactTable1 to Sales Transactions, and suddenly your question, ‘What were the top products in Sales Transactions?’ makes perfect sense. And don’t forget measures: instead of Total, call it Total Sales Amount, Copilot can now answer, ‘Show me Total Sales Amount by Region’ without guessing. Always use full, descriptive, human-readable names rather than abbreviations or system defaults. This not only helps Copilot, but also makes your reports much easier for other humans to read.
Descriptions. If you’re like me, you probably never thought there was much value in populating anything in the Description property, which is available for tables, columns, and measures in the Model view. But apparently, Copilot looks at that description info when it’s available to better understand what business users are asking for. And I think it’s a smart way to use this option. Now your creativity can simply fly, or you can let Copilot step in and help fill those empty Description fields for you.
I think the key in writing a description is to avoid redundancy. Don’t repeat what’s already obvious from the column name unless it actually adds clarity. Instead, enrich it with context. For example, for ProductID, you could add a description like: “Unique identifier for the product sold by the company.”
Linguistic Schema: Synonyms. This might feel similar to renaming tables and columns to make them more business-user friendly. But synonyms offer a better option: you can give end users different names without physically renaming the objects in your semantic data model. Essentially, it creates an extra naming layer on top of your real model, which might be clear to technical professionals but confusing for others. This additional synonyms layer can also provide multiple versions for a single name. For example, a Product table could have synonyms like Goods, Item, or Inventory, while a Transaction Date column could be referenced as Order Date, Sale Date, or Posting Date.
Linguistic Relationships. In the database world, a relationship usually defines how two or more tables are logically or physically connected. For example, both the Student and Course tables can be linked through the CourseRegistration table, since the unique identifiers from the first two tables exist in the third. But adding a more linguistic explanation, like “Student takes a course” or “Course assigned to registered attendees”, provides better context for future questions. Essentially, you’re helping your semantic data model become more understandable and approachable for users.
Prep Data for AI: Simplify the Data Schema. Sometimes having access to the full dataset gives you an optimal data discovery experience, no hidden elements, and you can track all movements of your data. But that comes at a cost: you need to understand how all semantic model entities are interconnected, and you must know the business purpose of various data attributes, like dates or amounts across different tables. When working with a modern AI assistant, that domain and technical knowledge might not be immediately available. By simply minimizing the scope of what you include or exclude for the AI to use, you can remove a lot of confusion and guide it toward a single, correct data point, a linguistically precise answer.
Prep Data for AI: Add AI Instructions. Now we’re getting somewhere, can we actually teach an AI to do better? Hmm, yes, we can ??. But, this is still about helping Copilot provide better context and reduce confusion. For example, a term like “Best Selling” could be mapped to “Most Products Sold”, “Total Coverage” could indicate “Number of cities where products are sold”, and “Stock Level” could be interpreted as “Inventory Count”.
Prep Data for AI: Verified Answers. This will take your AI “training skills” to a whole new level. You’ll have the chance to create linguistic constructs that improve consistency and increase Copilot’s accuracy. In simple terms, you’re adding an extra layer in your semantic model that Copilot will check first before looking elsewhere for answers. If you haven’t thought about it this way, you’re essentially training your job replacement, and now it’s crystal clear ??. But this is part of every healthy work environment, and we should be okay with that.
Summary. So, what am I thinking about all of this? There’s definitely a gap between how a Copilot AI assistant perceives your Power BI semantic data model and how you, as a professional, understand it. That gap often comes from your experience and business domain knowledge. Yes, AI is becoming more involved and intelligent, and eventually, some of this AI “training” may become unnecessary in future. But your data modelling skills remain highly relevant, you still need to understand the logic and physical design of your data assets. And I’ll say it again: understanding and learning about the business domain is very important for humans to continue coexisting with evolving AI. Personally, I want to remain a pragmatic optimist for as long as possible.