Getting Started with Copilot in Power BI - A Practical First Week Guide

Most of the Copilot in Power BI conversations I have with Australian organisations start the same way. Someone senior saw a demo, asked the BI team to "turn on Copilot", and the BI team came back a week later with a list of blockers nobody expected. Capacity licensing. A tenant setting that's off by default. A data residency question that the risk team wants answered in writing. And then, once it's finally on, the first few prompts return answers that are confidently wrong because the semantic model has columns called Amt_2 and FLAG_X.

None of this is a reason not to do it. Copilot in Power BI is genuinely useful once the groundwork is in place. But "getting started" involves more than clicking a button, and Microsoft's Get started with Copilot in Power BI tutorial is a good starting point that covers the mechanics. What I want to add here is the stuff we've learned from doing this with clients: what to sort out first, what to try in week one, and where people get tripped up.

The prerequisites, in plain terms

Copilot in Power BI needs a paid Fabric capacity (F2 or above) or a Power BI Premium capacity (P1 or above). Pro and Premium Per User licences on their own don't get you there. The workspace you're working in has to be assigned to that capacity. This is the first surprise for a lot of mid-sized businesses that have been happily running on Pro licences for years.

The smallest F SKUs are cheap enough to experiment with, and you can pause Fabric capacity when you're not using it, which is handy for a proof of concept. But be aware that Copilot consumes capacity units like everything else on that capacity. If you put it on the same F capacity that runs your overnight dataflow refreshes, and twenty people start firing off prompts at 9am, you'll see it in the capacity metrics app. We usually recommend a separate small capacity for the pilot so you can measure what Copilot actually costs you before it competes with production workloads.

Then there's the tenant setting. A Fabric administrator needs to enable "Users can use Copilot and other features powered by Azure OpenAI" in the admin portal. You can scope it to a security group, and you should. Rolling it out to a pilot group of fifteen people who know the data is far better than switching it on for everyone and fielding support tickets.

The data residency question

This one deserves its own section because it stalls more Australian rollouts than anything else.

Copilot in Power BI uses Azure OpenAI under the hood. If your capacity sits in a region where Azure OpenAI isn't available for the service, there's a separate tenant setting that allows data to be processed outside your capacity's geographic region. For a long time that applied to Australian tenants, and depending on when you read this, it may still apply to some features.

My advice: don't guess. Check the current Microsoft documentation for Australia East and Australia Southeast, read exactly what leaves the region (prompts and the relevant metadata and data needed to answer them, not your whole dataset), and get your privacy or risk person to sign off in writing. For most commercial organisations this is a fifteen-minute conversation. For government, health and financial services clients it can take a few weeks, so start it early. I've seen a pilot sit idle for a month because nobody raised the residency question until the day before launch.

Prep the semantic model before anyone types a prompt

Here's the thing that matters most and gets skipped most often. Copilot reads your semantic model. It looks at table names, column names, measure names, descriptions and relationships, and uses that to work out what you're asking about. If your model is a mess, Copilot's answers will be a mess.

Before turning it on, we do a quick model tidy-up pass:

• Rename things so a human could understand them. fact_sales_v3 becomes Sales. CustNm becomes Customer Name. This sounds trivial and it's the single biggest improvement you can make.
• Add descriptions to measures and key columns. Copilot uses these. A measure called Revenue with a description of "Invoiced revenue excluding GST, recognised on invoice date" gets used correctly far more often than one with no description.
• Hide the plumbing. Surrogate keys, staging columns, helper measures. If a report user would never put it on a visual, hide it. Copilot then has fewer wrong options to pick from.
• Check your relationships and date table. A proper marked date table makes time-based questions ("compare this quarter to the same quarter last year") work far more reliably.
• Set up synonyms in the linguistic schema if your business uses multiple words for the same thing. Some teams say "branch", others say "store", others say "site".

There's also the "Prep data for AI" area in Power BI Desktop, which lets you set AI instructions, simplify the schema Copilot sees, and define verified answers. It's worth the time. A couple of hours spent here saves weeks of people losing trust in the tool because it gave them a weird answer in their first session.

What to actually try in week one

Once it's on and the model is in decent shape, here's the order I'd suggest for a pilot group.

Start with summaries of existing reports. Open a report people already know well and ask Copilot to summarise the page. This is low risk because the user already knows what the answer should look like, so they can judge whether Copilot got it right. It's also the fastest way for people to build an intuition for what it's good at.

Then try asking questions about the data. The standalone Copilot experience and the report pane both let users ask things like "which product categories declined in Queensland last month?" Encourage people to be specific. Vague prompts get vague answers. "Show me sales" is a bad prompt. "Show me monthly sales by region for the last 12 months as a line chart" is a good one.

Try generating a report page. Copilot can create a report page from a prompt, and the result is a decent first draft. It's not a finished report. In our experience it gets the visual types roughly right and the layout is serviceable, but you'll still want a BI developer to tidy formatting, check the measures it chose, and apply your theme. Think of it as saving the first 30 minutes, not the whole job.

Try the narrative visual. Dropping a Copilot narrative visual onto a report gives you a text summary that updates as filters change. Executives tend to like this a lot. Just be sure someone has checked that the narrative is reading the right measures.

Try DAX help in Desktop. For developers, asking Copilot to write or explain DAX queries in the DAX query view is a real time saver. It's not perfect with complex time intelligence or iterator functions, but it's good at explaining what an existing measure does, which is great when you inherit someone else's model.

What's still rough

I'll be honest about the limitations because overselling this does more damage than underselling it.

Copilot can produce answers that look authoritative and are wrong. Usually this is because it picked the wrong measure (gross instead of net, for example) or misread an ambiguous column name. Users need to be trained to check which fields Copilot used, not just read the answer. The good news is the Copilot pane shows its working in most cases. The bad news is most people don't look.

It's also inconsistent. The same prompt on the same data can produce slightly different visuals or summaries on different runs. For exploratory analysis that's fine. For anything going into a board pack, a human should be producing the final version.

And it's only as good as your data model, which I've already said but will say again. We've had clients conclude "Copilot doesn't work" when the real issue was a model with 400 columns, no descriptions and three different date fields. Fix the model and the results improve a lot.

Training is not optional

The organisations that get value from Copilot in Power BI are the ones that spend an hour or two teaching their pilot group how to prompt well and how to sanity-check outputs. The ones that just turn it on and send an email tend to see usage spike for a week and then fall away.

A simple format that works: a 90-minute session with your own data, where people try prompts live and you talk through why some worked and others didn't. Keep a shared list of prompts that worked well for your business. That list becomes surprisingly valuable after a month. We run this kind of hands-on session as part of our Copilot training, and it consistently makes the difference between a pilot that sticks and one that quietly dies.

A realistic rollout sequence

If I were starting from scratch at a typical Australian mid-market organisation, here's what I'd do:

1. Confirm licensing and stand up a small F SKU for the pilot.
2. Resolve the data residency question with risk or privacy, in writing.
3. Enable the tenant setting for a security group of 10 to 20 people.
4. Pick one or two semantic models that are well used and well understood. Tidy them up properly.
5. Run a hands-on training session with the pilot group.
6. Watch capacity usage and collect feedback for four weeks.
7. Decide whether to expand, and to which models.

That's a six to eight week process if you move at a sensible pace. It's slower than "turn it on", but you end up with something people trust and keep using.

Where this fits in the bigger picture

Copilot in Power BI is one piece of a broader shift towards people asking questions of their data in plain language rather than waiting for a report to be built. It works best when the underlying data platform is solid. If your semantic models are well designed and documented, Copilot is a nice multiplier. If they're not, it surfaces those problems very quickly, which is useful in its own way.

If you're working through a rollout and want a hand with model prep, capacity planning or training, our Power BI consultants do this regularly, and we can also help if you're thinking about how Copilot fits into a broader AI for business intelligence approach. Either way, sort the model first. Everything else is easier after that.