AI Instructions in Power BI - How to Tell Copilot What Your Business Means

Ask Copilot in Power BI "what were sales last year?" on an Australian company's model and you've handed it two ambiguous terms in five words. Which sales figure, gross or net of returns, with or without GST? And which year? Calendar 2025, or the financial year that ended on 30 June?

A human analyst who has been in the business for a month knows the answers. Copilot doesn't, unless you tell it. AI instructions are how you tell it.

Microsoft's documentation on AI instructions describes them as a way for semantic model authors to provide context, business logic and specific guidance directly on a model. In plainer terms, it's a text box where you write down the things a new analyst would need to be told in their first week. Copilot reads it every time someone asks a question against that model.

Of the three "prep data for AI" features in Power BI, this is the one with the best return on time. It's also the one that's easiest to do badly.

Setting it up

The mechanics take about two minutes.

In Power BI Desktop, select Prep data for AI on the Home ribbon. In the service, the same button is on the ribbon for the selected semantic model. Go to the Add AI instructions tab, type your instructions, and select Apply. When you close the dialog the instructions are saved to the model.

Three prerequisites: a semantic model, Copilot enabled for your organisation, and Power BI Q&A enabled for the model. That last one catches people. If the tabs in the dialog are disabled, Q&A is off, and you can turn it on from the same place.

To test in Desktop, open the Copilot pane, use the skill picker to choose "Answers questions about the data", and ask something your instructions should influence. One annoying detail: every time you edit the instructions you need to close and reopen the Copilot pane before the changes take effect. I have watched people spend twenty minutes rewriting an instruction that was fine, because they were still testing against the old version.

Once the model is published, the instructions apply to every Copilot experience that uses that model. Every report built on it inherits them.

What to put in them

Microsoft groups the common uses into two buckets, and they're a sensible way to think about it.

Business context and interpretation. Their examples include "Busy season is October to February", "A lower attrition percent is more positive", and "When a user mentions ABCD, they're referring to the total invoice field". This is the tribal knowledge. Copilot has no idea whether a number going down is good news unless you say so.

Analysis rules. Things like "Always analyse sales on a quarterly basis", "Use the sales_fact table as the primary source for all sales-related questions", or "When a user asks about product sales, always ask for clarification on location". These steer how Copilot slices things, and when it should stop and ask.

The documentation includes a full example for a sales model, grouped under headings: Metrics, Dates, Ambiguity, Terminology, Customer identification. One part of it made me smile:

Dates
- The fiscal year starts on July 1 and is named for the year it ends.
  FY2027 means July 1, 2026 through June 30, 2027.

Microsoft's own financial year happens to line up with ours, so their example is almost copy-and-paste for an Australian business. I'd treat some version of that instruction as mandatory on any model here. Without it, "this year" and "last year" are a coin toss, and during July and August the results get properly confusing.

Here's roughly what I'd start with for a typical Australian sales model:

Metrics
- When a user asks about "sales" or "revenue" with no other qualifier,
  use [Net Sales]. [Net Sales] is in AUD, excludes GST, and is after
  discounts and returns.
- For margin percentage, use [Gross Margin %]. Never average
  line-level margin percentages.

Dates
- The financial year starts on 1 July and is named for the year it
  ends. FY26 means 1 July 2025 to 30 June 2026.
- "This year" and "last year" mean financial year unless the user
  says calendar year.

Terminology
- "Branch" and "store" both mean 'Location'[Location Name].
- "The eastern states" means NSW, VIC and QLD.

Ambiguity
- If "performance" could mean sales, growth or margin and the user
  hasn't said which, ask.

Short, grouped, and specific. Use your real measure and column names in the DAX-style notation so there's no doubt about which object you mean.

Writing them well

AI instructions are a prompt. Everything you know about writing prompts applies, and Microsoft's guidance here is solid. The parts I'd underline:

Assume Copilot knows nothing about your business. The docs contrast "You're a seasoned BI Analyst who is detail-oriented" with a version that says who the analyst works for and what the responses should focus on. I'd go a step further and skip the persona fluff altogether. "Use [Net Sales] for revenue" does more work than any amount of role-play.

Say what not to do. Microsoft's example: for Total Active Partners, use the Monthly Active Partner Count measure, and don't filter on the Customers table. Negative instructions are useful where your model has a tempting wrong path. Most models have at least one. The example even calls out a column that looks like a customer ID and isn't.

Give examples of values. If product names, region codes or status values are not self-explanatory, list a few. "Status 'C' means cancelled, 'H' means on hold" saves a lot of wrong answers.

Group with headings. The model reads structure. Date logic together, metrics together, terminology together.

Keep it focused. This is the one people ignore. The docs say fewer focused instructions can be more effective than many broad ones, because conflicts and complexity confuse the model. There's a 10,000 character limit, and teams treat it as a target. Don't. The best instruction sets I've seen are well under half that. Every extra line is another chance for two rules to contradict each other, and when they do, you won't get an error. You'll get inconsistent answers and no clue why.

Order matters, apparently. Microsoft notes that the order of instructions can affect output and suggests testing variations. I find this a bit unsatisfying as engineering guidance, but it matches what we see. If an instruction keeps getting ignored, try moving it up or rewording it before you assume it's impossible.

The limits, which are real

The considerations section in the docs is long, and I'd encourage every model owner to read it before promising anything to stakeholders. The ones that matter most in practice:

Instructions are guidance, not rules. The docs are blunt: the LLM interprets them, and there's no guarantee it will follow them exactly. So AI instructions are not a control. They are not security, they are not a substitute for row-level security, and they are not a way to enforce a definition. If a number has to be right every single time, put the logic in a measure and consider a verified answer for the common question. Use instructions to point Copilot at that measure.

They're model-level only. You can't set different instructions per report, and you can't vary them by persona. If finance and sales share a model and mean different things by "revenue", instructions won't settle it. That's a modelling conversation, and probably a conversation between two department heads as well.

Users can't see them. Consumers have no way to view the instructions an author applied, and they can't turn them off. I understand why, but it has a consequence. If you've told Copilot to default to two states, as Microsoft's own example does with Washington and California, a user asking about "total sales" gets a filtered number and may not realise it. They can expand how Copilot arrived at the answer, but only if they know to look. My advice is to avoid default filters in instructions unless the model is used by one team who all know about it. And publish your instructions somewhere your users can read them, even just a page on the intranet.

They don't control Copilot's behaviour generally. Instructions can't disable Copilot features, can't change visual formatting or theming, and don't apply to general chat that isn't about the data.

A Desktop quirk. Instructions might not be respected in Desktop when Copilot is creating a page, suggesting page topics or summarising the model. The workaround in the docs is to use the skill picker and select only "Create new report pages".

No upload. You can't currently upload instructions into the dialog in Desktop. So keep the master copy in a text file in source control next to the model, and paste it in. You'll want the version history anyway. When answers change after an edit, you need to be able to see what was edited.

How to iterate

Microsoft says you'll often need to iterate, which undersells it. You will always need to iterate.

The process we use with clients is simple. Before writing any instructions, collect twenty to thirty real questions from the people who'll use the model. Ask them all with no instructions in place and record what comes back. That's your baseline, and it tells you where Copilot is already fine. Don't write instructions for things that already work.

Then write instructions only for the failures. Re-run the whole list after each change, not just the question you were fixing, because a new instruction can break something that used to work. Keep the list. Run it again whenever the model changes.

It's a regression test suite for a text box. That sounds like overkill until the first time a harmless-looking edit quietly changes the answer to the CEO's favourite question.

A lot of what goes wrong with instructions comes from asking them to compensate for the model. If you find yourself writing "when the user says X, ignore table Y and use column Z from table W, except when...", stop and fix the model. Rename the column. Hide the table using the AI data schema. Instructions should carry business context. The model should carry structure. I covered that groundwork in an earlier post on preparing your Power BI data for AI.

Worth doing?

Yes. An hour spent on a tight set of AI instructions will noticeably improve Copilot's answers on most models, and the financial year instruction alone pays for the effort in Australia.

Just be clear with yourself about what they are: a well-placed hint to a language model. Useful, cheap, and not something to rest a compliance argument on.

If you want help getting a semantic model ready for Copilot, including the instructions, the schema clean-up and the testing, that's work our Power BI consultants do regularly. We also cover it as part of broader AI for business intelligence engagements. Or contact us and tell us what Copilot is getting wrong. That's usually the fastest place to start.

Reference: Prepare your data for AI - AI instructions on Microsoft Learn.