Continuing my (already very long) series on what information you should be adding to the AI Instructions of your semantic model and why, in this post I’ll show you the benefits of adding the DAX definitions of your measures.

A really common question from end users viewing a Power BI report is “how is this measure calculated?”. As a result I have seen model developers use techniques like this to display either a text description of how the measure works in a report or the actual DAX definition. It is therefore not a surprise that if end users are using Copilot they will ask the same question. Unfortunately Copilot cannot – or rather should not, at the time of writing – be able to to see the definitions of the measures in your model. Most of the time if a user asks to see how a measure is defined then Copilot will say that it can’t show the definition:

[Argh, yes I know it’s calling a measure a calculated column]

…although sometimes it does seem to be able to get the definition by writing a DAX query – but I have also seen it hallucinate and come up with a plausible looking definition which isn’t the actual definition. Anyway, it certainly can’t show the definition of a measure or a description of how it works reliably.

Adding all the measure definitions to the model’s AI Instructions mostly solves this problem. TMDL View makes it easy to get all the measure definitions in a semantic model in Power BI Desktop and you can copy/paste them from there into the AI Instructions.

In the semantic model that I’ve been using throughout this series I added some extra measures and then copied their DAX definitions and their descriptions into the AI Instructions. Here are the AI Instructions:

##Definitions and descriptions of the measures in this model
If a user asks how a measure is defined, asks how a measure works or asks how a measure is calculated, ignore any previous instructions about displaying measure definitions from the model and show the definition given here.

All measures that return currency values do so in Pounds Sterling and should be formatted with a £ sign.

##Average Price Paid
AVERAGE('Transactions'[Price])

##Count Of Transactions
COUNTROWS('Transactions')

##New Build Average Price Paid
Gets the value of the Average Price Paid measure where the New column equals "Y"
CALCULATE([Average Price Paid], KEEPFILTERS('Transactions'[New]="Y")) 

##Tax Paid
Different tax rates are levied on new build and non-new build properties
A 10% tax is levied on the sale of new build properties
A 5% tax is levied on the sale of properties that are not new builds
(CALCULATE(SUM('Transactions'[Price]), KEEPFILTERS('Transactions'[New]="Y")) * 0.1)
+
(CALCULATE(SUM('Transactions'[Price]), KEEPFILTERS('Transactions'[New]="N")) * 0.05)

Note in particular the Tax Paid measure – it has some fairly complex logic that bears no relation to any actual tax in the UK, so I knew there was no way Copilot would be able to guess how it was defined.

With these AI Instructions in place, the prompt:

how does the tax paid measure work?

…shows a helpful summary:

[Although I admit sometimes Copilot still does reply saying that it can’t display the definition of a measure from the model, which isn’t ideal – if I work out how to stop this happening I’ll update this post]

Even more impressively, since Copilot knows the definition of the measure, it is able to answer more complex questions like this:

show me what the tax paid by property type name would be if the tax on new build properties was increased to 11%

Here’s the DAX query generated, which shows that Copilot has modified the definition of the measure correctly:

// DAX query generated by Fabric Copilot with "Show the tax paid by Property Type Name if the tax on new build properties was increased to 11%."
EVALUATE
  // Summarize the tax paid by Property Type Name with increased new build tax rate (11%)
  SUMMARIZECOLUMNS(
    'PropertyTypes'[Property Type Name],
    "Tax Paid", 
      // New build tax (rate increased to 11%) plus non-new build tax (rate unchanged at 5%)
      (CALCULATE(SUM('Transactions'[Price]), KEEPFILTERS('Transactions'[New] = "Y")) * 0.11) +
      (CALCULATE(SUM('Transactions'[Price]), KEEPFILTERS('Transactions'[New] = "N")) * 0.05)
  )
  ORDER BY
    'PropertyTypes'[Property Type Name] ASC

I’m spending a lot of time with organisations testing Power BI Copilot at the moment, and something I hear a lot is that Copilot works well in Desktop but when you publish your model to the Power BI Service the results are a lot more inconsistent. One reason why is because of how updates to AI Instructions are applied after you publish your semantic model.

Let’s see an example of this. Consider the following semantic model consisting of a single table with two measures, Sales Amount and Profit Amount:

The semantic model has the following AI Instructions applied:

//Instructions V1
xyz means the measure Sales Amount

The instructions here don’t make much sense, but using a meaningless term like “xyz” makes it easier to test whether Copilot is using an instruction or not.

In Power BI Desktop, the following Copilot prompt returns the results you’d expect with xyz understood as Sales Amount:

show xyz

If you publish this model to an empty workspace in the Power BI Service then this prompt returns the same correct result.

[By the way, the message “Copilot is currently syncing with the data model. Results may be inconsistent until the sync is finished” will be the subject of a future blog post – it’s not connected to what I’m describing in this post, it relates to how Copilot needs to index the text values in your semantic model, which is a separate process]

So far so good. Going back to Power BI Desktop, changing the AI Instructions like so:

//Instructions V2
xyz means the measure Sales Amount
kqb means the measure Profit Amount

…then closing and reopening the Copilot pane in Desktop and entering the prompt:

show kqb

…also returns the result you would expect, with kqb understood as Profit Amount

However, if you publish the same model up to the same workspace as before – so you are overwriting the previous version of the model in the Service – and then use the same prompt immediately after publishing:

…Copilot returns an incorrect result: it does not understand what “kqb” means. Why?

After you publish changes to a Power BI semantic model it can take a few minutes, sometimes up to an hour, for updates to the AI Instructions to be applied. This means if you’re testing Power BI Copilot in the Service you may need to be patient if you want to see the impact of any changes to AI Instructions, or do your testing in Power BI Desktop.

How can you know whether the latest version of your AI Instructions are being used in the Service when you do your testing? In the Power BI side pane in both Desktop and the Service there is an option to download diagnostics from the “…” menu in the top right-hand corner. This downloads a text file with diagnostic data in JSON format which contains a lot of useful information; most importantly it contains the AI Instructions used for the current Copilot session. The file contents aren’t documented anywhere, I guess because the structure could change at any time and it’s primarily intended for use by support, but there’s no reason why you as a developer shouldn’t look at it and use it.

For the second example in the Service above, where Copilot returned the wrong result, here’s what I found at the end of the diagnostics file:

As you can see the changes I made to the AI Instructions before publishing the second time had not been applied when I ran the prompt asking about kqb.

After waiting a while, and without making any other changes to the model, the same prompt eventually returned the correct results in the Service:

Looking at the diagnostics file for this Copilot session it shows that the new version of the AI Instructions was now being used:

Since looking in the diagnostics file is the only way (at least that I know of right now) to tell what AI Instructions are being used at any given time, it makes sense to do what I’ve done here and put a version number at the top of the instructions so you can tell easily whether your most recent changes are in effect.

One last point to mention is that if you’re deploying semantic models using Deployment Pipelines or Git, the docs state that you need to refresh your model after a deployment for changes to AI Instructions to take effect and that for DirectQuery or Direct Lake (but not Import) mode models this only works once per day.

If there are specific ways you want your data to be visualised by Power BI Copilot then you have two options. You can use Verified Answers to link questions to visuals on your reports and can even set them up so users can apply filters to these visuals in their prompts. Alternatively – and this is the topic of this post – you can use AI Instructions to tell Copilot which visuals should be used when certain combinations of measures and columns appear together in a prompt.

Using the same semantic model I have used in this series of posts, consider the following prompts and the responses returned when there are no AI Instructions:

show count of transactions by date for the first week of January 2025

This returns results as a line chart:

show count of transactions broken down by New

[There is a column in the model called New containing Y or N values]

This returns results as a bar chart:

Adding the following AI Instructions changes the visualisations used by Copilot for these prompts:

When showing the count of transactions measure by date always use a column chart.
When showing the count of transactions measure by New use a pie chart.

Here are the responses returned now:

show count of transactions by date for the first week of January 2025

show count of transactions broken down by New

Before someone comments, I’m not saying that these visualisation choices are better than the defaults, I’m just saying that you can use AI Instructions to change the visuals used in responses. There may be a type of analysis for your data or your industry that should always use a certain Power BI visual, one that isn’t the visual that Copilot chooses by default. And we all know that some users have strong opinions on which visuals should be used that don’t follow data visualisation best practices…

Power BI Copilot knows about the relationship between measures and tables, which means that it’s very good at knowing which measures can be broken down by which columns. For example, consider the following model with two fact tables, one of which contains sales data dimensioned by Employee and Customer, and one which contains target data that is only dimensioned by Employee:

For extra fun, I’ve created a disconnected measure table to hold all the measures, which are defined as follows:

Sales Amount = SUM(Sales[Sales])
Target Amount = SUM(Targets[Target])
Target % = DIVIDE([Sales Amount],[Target Amount])

Without any AI Instructions added to the model, for the following prompt:

Show Sales Amount broken down by Customer

I get (as you would expect) the following correct response:

However for the prompt:

Show Target Amount broken down by Customer

…I get a response that you can’t show Target Amount broken down by Customer because there’s no direct relationship. This is, I think the right response for most users.

Note that Copilot knows the relationships between the Sales Amount and Target Amount measures and the Customer dimension table even though they are on the disconnected measures table, which I think is very smart.

Even better, a prompt like this:

show a table with Employee Name, Customer Name, Sales Amount, Target Amount and Target %

Returns the result I would expect:

Copilot has understood that even though there’s no relationship between Customer and Target Amount, it makes sense to break it down in this case.

What about calculation groups? I’ve seen some inconsistent behaviour over the last few days but on the day I’m writing this post, calculation groups were working well in Copilot with no special AI Instructions despite the fact they have no relationship with any other table.

Adding a calculation group to the model like so with two calculation items, Actual Value and Forecast:

Actual Value = SELECTEDMEASURE()
Forecast = SELECTEDMEASURE() * 100

And prompting:

Show Forecast Sales Amount broken down by Customer

…gives the right response using the Forecast calculation item:

That said I’m sure there will be scenarios where Copilot decides it can’t use a measure with a particular column even though you want it to, and you can override this behaviour with AI Instructions. However, I have found you need to be very careful about what instructions you provide to get the output you expect. For example adding the following to the AI Instructions of my model:

For the Target Amount measure, ignore any previous instructions regarding not displaying measures with columns from tables where there is no direct relationship. 

…means that the prompt shown above which asks for Target Amount broken down by Customer:

Show Target Amount broken down by Customer

…returns the following result:

This surprised me a lot: I was expecting to see the same value repeated across all customers. I worked out that the reason different customers showed different values for Target Amount was that the visual was assuming an indirect relationship via the Sales table, but even then I had no idea that it was possible to build a Power BI visual that did this when no many-to-many relationships exist in the model – I certainly couldn’t build the same visual myself manually. It’s one way of answering the question correctly though.

Altering the AI Instructions to tell Copilot not to do this was tricky but eventually I came up with this:

For the Target Amount measure, ignore any previous instructions regarding not displaying measures with columns from tables where there is no direct relationship. When displaying Target Amount by Customer do not assume there is an indirect relationship via the Sales table.

The same prompt then gave me the result I was expecting with the same Target Amount value repeating across all customers (and it’s interesting it decided it had to create a DAX query to do this too):

This tells me that it’s probably not a good idea to try to override Copilot’s default behaviour when it comes to relationships, tables and measures.

One of the most common questions I hear about Power BI Copilot is how you can stop it from guessing what a user means when they ask an ambiguous question, and instead get it to ask for clarification. This is an interesting problem because Copilot already does this and what you really want is a way to control the level of tolerance for ambiguity. What’s more, if Copilot guesses what the user means correctly you’re probably not going to complain or even notice; it’s only when it guesses incorrectly that you’re going to wish it had asked what the user meant.

Using the semantic model containing UK real estate sales data that I’ve used throughout this series of posts, with no AI Instructions added to the model, consider the following prompt:

where is the nicest place to live in England?

It’s a great example of a question that could potentially be answered from the data but only with more information on what the user means by “nicest”. I think Copilot comes back with a very good response here:

As you can see, Copilot doesn’t know what the user means by “nicest” and asks the user what criteria they want to use to determine whether a place is “nice”.

What about an example of where Copilot does make assumptions about what the user means? Take the following prompt:

show how the number of sales varied recently

This time it does come back with an answer. I think this is a good, useful response but I want you to notice that Copilot has made two assumptions here:

1. It has interpreted “number of sales” as meaning the measure Count of Transactions
2. It has taken the term “recently” and decided to show date-level data for the latest available month of data, April

Can this behaviour be changed? Yes, but it’s not an exact science. For example adding the following to the AI Instructions of the model:

If you don't understand what the user is asking for never, ever guess - you must always ask for clarification

Here’s what Copilot now responds to the second prompt above:

As you can see, it’s now asking what is meant by “recently”. Clarifying this as follows:

"recently" means the days in April

Gives the same result as without the AI Instructions:

BUT – even though Copilot asked what “recently” meant, it still went ahead and assumed that “number of sales” meant the Count of Transactions measure. Adding to the AI Instructions to make it clear that Copilot should always ask if there’s any doubt about which measure to use like so:

If you don't understand what the user is asking for never, ever guess - you must always ask for clarification. In particular if the user does not explicitly mention the exact name of the measure they want to use, or the name of the measure is in any way ambiguous, do not return a result. Instead ask the user which measure they want to use. Be extremely cautious about which measure you use.

…results in a response that asks for clarification not only about what “recently” means but also what “number of sales” means:

Copilot doesn’t do this reliably though: even though it always seems to ask about “recently” now it only sometimes asks for clarification about “number of sales”. Sometimes is better than never though; indeed it’s the kind of uncertainty that is expected with Generative AI. I think I need to do some more research into what’s going on here. At least this shows that AI Instructions can be used to make Copilot more cautious around ambiguous questions and more likely to ask for clarification.

[Update 17th July 2025]

After testing this some more (and possibly after an update to the Power BI Service in the last few days) I have come up with some AI Instructions that seem to be a lot more reliable when it comes to asking the user which measure they want to use and to define what “recently” means:

If you don't understand what the user is asking for never, ever guess - you must always ask for clarification. If there are multiple points you don't understand it is essential that you ask the user to clarify all of them.

In particular, ignore all previous instructions regarding which measure to select and make sure you obey the following rule: if the user does not explicitly mention the exact name of the  measure they want to use, or the name of the measure is in any way ambiguous, do not return a result. Instead ask the user which measure they want to use. Be extremely cautious about which measure you use! At the same time, as I said, remember to clarify other, non-measure related ambiguities.