Copilot in Power BI - What Microsoft's End-to-End Tutorial Gets Right About Rollout

Most Australian organisations I talk to already have Copilot in Power BI available to them. They're on a Fabric capacity, the tenant setting is on (or could be by lunchtime), and the button is sitting there in the left navigation. Very few of them are getting much out of it.

The usual story goes like this. Someone in finance or sales ops clicks the Copilot button, types a reasonable question, and gets back an answer that is either wrong or so hedged it's useless. They try twice more, shrug, and go back to exporting to Excel. Six months later the organisation's official position is "we tried Copilot, it wasn't ready".

Microsoft has published a tutorial series that walks through Copilot in Power BI from start to finish, and the introduction to that series is short. You could read it in three minutes. But the way it frames the work is the thing most failed rollouts missed, so it's worth spending some time on.

Two halves, two different groups of people

The tutorial splits the scenario in two.

The first half is for developers, meaning whoever builds and owns the semantic model. Their job is to make the model AI-ready. In Microsoft's words that means simplifying the schema, creating verified answers, and providing AI instructions. Then they test the setup and publish it.

The second half is for business users. Their job is to explore data with natural language: ask questions, interpret the answers, dig further into what comes back, and summarise what they found.

That sounds obvious written down. In practice, almost every disappointing Copilot rollout we've been asked to look at skipped the first half entirely. The licence got switched on, an email went out telling staff they could now "chat with their data", and business users were pointed at semantic models that had been built years earlier for a completely different purpose, which was feeding a fixed set of report visuals designed by someone who knew what every cryptic column name meant.

A report author can work with a column called Amt_Net_2 because they built it. Copilot can't phone them to ask what it is. Neither can the sales manager typing the question.

So the framing matters. Copilot in Power BI is a two-sided feature. One side is a modelling and curation job that belongs to your BI team. The other is a usage habit that belongs to everyone else. If you only do the second, you get the "it wasn't ready" outcome.

The developer half is where the effort goes

The tutorial names three preparation tools, and all three live under the Prep data for AI button in Power BI Desktop and in the service.

Simplifying the schema. You choose which tables, columns and measures Copilot is allowed to consider. Most production models carry a lot of scaffolding: key columns, sort-order helpers, staging tables, half-retired measures nobody dared delete. None of it belongs in an answer. Cutting it out of Copilot's view is the cheapest accuracy improvement available, and it's usually an afternoon's work.

Verified answers. For the questions that get asked every week, you can pin a specific visual as the approved response. When someone asks something close to the trigger phrases, Copilot returns your visual instead of improvising one. I like this feature a lot, mostly because it deals with the scariest failure mode. The CFO asking "what's our revenue this quarter" should never get a freshly improvised calculation.

AI instructions. Free-text guidance attached to the model. Which measure "sales" means, when your financial year starts, what the internal jargon maps to. I've written a separate post on AI instructions because there's a fair bit to say about writing them well.

Then test, then publish. The tutorial is explicit that testing sits before release, and I'd go further: testing should be done by someone who didn't build the model. The builder asks questions the way the model is structured. Real users don't.

One practical note from the docs. You can author all of this in both Power BI Desktop and the Power BI service, and people can consume it anywhere Copilot in Power BI is available. That's handy, but it also means you need to decide where the source of truth lives. If your team deploys models through pipelines or source control, somebody editing AI instructions directly in the service on a Tuesday afternoon is going to get overwritten by the next deployment. Agree on the process before you start.

The business user half is a skill, not a switch

The second half of the tutorial is about asking, interpreting, digging and summarising. I'd put the emphasis on "interpreting".

Copilot answers are non-deterministic. The same question on the same data can come back worded differently, or occasionally with a different cut of the numbers. Microsoft says this plainly in the later parts of the series and tells you to set expectations with users about how to validate what they get. That is good advice that almost nobody follows.

When we run Copilot training for teams, the Power BI portion spends more time on checking answers than on writing prompts. Things like opening the "How Copilot arrived at this" panel to see which filters were applied. Noticing when "last year" was interpreted as the last twelve months and not the last financial year. Knowing which numbers in the business are settled and which are still being argued about between departments. A person who can do those things gets a lot of value from Copilot. A person who can't is going to paste a wrong number into a board paper eventually.

So yes, switch it on for business users. But budget an hour or two of proper training per team, using their own data and their own questions. Generic "prompting tips" slides don't help much here.

About the sample scenario

The tutorial's sample data is a software company's sales channel. Sales managers track direct and partner sales, looking at opportunities and revenue by region, deal size and channel.

It's a good teaching dataset and you should work through it. Just keep in mind how different it is from what you have. It's one clean star schema with one definition of revenue and friendly names. Your environment probably has four models that each define revenue slightly differently, a date table with both calendar and financial year columns, and a region hierarchy that was reorganised in 2023 and never fully fixed.

Everything works beautifully on sample data. That's what sample data is for. The value of running the tutorial is that your team learns the mechanics on something that behaves, so that when they turn to your real model and Copilot struggles, they can tell the difference between "I'm using the tool wrong" and "the model needs work".

What I'd watch out for

A few honest caveats.

The tutorial says up front that it includes preview features and doesn't cover everything. Take that seriously. Copilot in Power BI has changed a lot over the past eighteen months and the screens you see in a tutorial can be a release behind what's in your tenant. Don't write internal training material with too many screenshots.

Prep data for AI depends on Power BI Q&A being enabled for the model. If the tabs in the dialog are greyed out, that's why. It trips people up more often than it should.

Licensing and capacity still matter. Copilot needs a paid Fabric or Premium capacity and an admin to enable it for the tenant, and requirements have shifted more than once, so check the current documentation before you promise anything to the business. If you're in a regulated sector, also check where your Copilot requests are processed. There's a tenant setting governing whether data can be processed outside your capacity's geographic region, and your risk team will want to know about it before go-live, not after.

And the big one: none of this fixes a bad model. If your measures are wrong, Copilot will repeat the wrong number with great confidence and nice formatting.

How I'd use this tutorial

If I were running BI for a mid-sized Australian business and wanted to find out whether Copilot was worth backing, I'd do this.

Give one model owner and one business user half a day to complete the Microsoft tutorial series on the sample data. Together, in the same room if possible. The model owner needs to see how a business user phrases things, and the business user benefits from seeing what's behind the curtain.

Then pick one real semantic model. Choose the one that already generates the most ad hoc "can you just pull me a number" requests, because that's where the payoff is. Apply the three preparation steps to it. Write down twenty questions people have asked about that data in the last month and test every one. Fix what fails, either in the prep settings or in the model itself.

After that, release it to a small group, ten people or so, with a short training session and a channel where they can post answers that looked wrong. Review that channel weekly for a month.

That's a pilot you can learn from. At the end of it you'll know how much preparation a model needs, how your people ask questions, and whether the answers hold up. That's a much better basis for a decision than a tenant-wide switch-on followed by silence.

We do this kind of work with clients regularly through our Power BI consulting practice, and for organisations building on Fabric more broadly through our Microsoft Fabric consultants. If you'd like a second opinion on whether your models are in good enough shape for Copilot, get in touch. It's usually a short conversation, and sometimes the answer is "fix these three things first".

The tutorial itself starts here: Copilot in Power BI tutorial - End-to-end overview.