Claude × Microsoft Power BI

Your Power BI just learned to answer.

Ask a question the way you'd ask a colleague, and get the number back from the reports you already have. Claude reads your existing Power BI. Nothing new gets built, and there's no copy of your warehouse to maintain.

Running in a live environment today Four dashboard areas Read-only by design
Claude, connected to Power BI
What were sales this quarter vs last year?
Used Power BI MCP integration
Execute query · Sales & Customer model
Compared Q3 to the same period last year, on invoice date4s

Sales for Q3 so far (1 July–18 September) are £1.84M across 412 invoices, counted on invoice date.

That is 11% ahead of the same period last year, which finished at £1.66M. The quarter isn't closed, so this figure keeps moving until the end of September.

Sales by quarter£ millions
1.66Q3 25 1.72Q4 25 1.48Q1 26 1.59Q2 26 1.84Q3 26

Try one
Answers come from the last successful Power BI refresh Illustrative figures
The everyday friction

You already know the number exists. Somewhere.

Nobody here is short of dashboards. What people are short of is a fast route through them. So the question goes into a chat message instead, and somebody on the BI team stops what they were doing.

1Work out which report it's inSeveral dashboard areas, and plenty of pages between them.
2Open Power BI and find the workspaceThen the right report, then the right page.
3Set the filtersQuarter, region, product line. Get one of them wrong and the number is wrong.
4Read the figure off a visualAnd hope the visual measures what you think it measures.
5Have a follow-up questionGo back to step two.
6Give up and message the BI teamThey stop what they were doing. You wait.
6 stepsbefore you have a number
2 peopleyour time and someone else's
Unknownhow long the wait is
Recorded, not rendered

Two minutes inside a real session.

A screen recording from a live Power BI environment. Same reports, same permissions, no test data. Watch what happens between the question and the answer: Claude finds the report, reads the semantic model, writes the query, then tells you what the number does and doesn't cover.

Silent screen capture, no narration 2 min 22 sec · nothing to listen for

Everything you see happens inside Claude. Power BI is never opened, and the report itself is never modified. Claude is reading the same semantic model the dashboard reads.

Under the hood

Five steps, and four of them happen once.

The connection runs on Microsoft's Remote Power BI MCP Server. Microsoft runs it. There is no middleware for your team to host, no copy of your warehouse, and no new semantic model to maintain.

Step 1 of 5

Your Fabric administrator switches it on

Microsoft ships a Remote Power BI MCP Server. It gets enabled in your Fabric tenant settings by whoever already administers Power BI. That's a setting, not a build. We review the environment with them first and confirm what needs to be true before anything else starts.

Nothing is installed on your network
No MCP server for your team to host or patch
Power BI stays the source of the reporting data
How a question reaches your data A question goes from you to Claude, through the Microsoft-hosted Power BI MCP server to the existing semantic model behind your report. Power BI applies your permissions and Row-Level Security before any result is returned. No copy of your warehouse is made and nothing is written back. You plain English Claude reads + explains Power BI MCP Microsoft-hosted Semantic model your existing report Permissions + RLS applied by Power BI No copy of your warehouse. Nothing is written back.

Swipe the diagram to see the whole path

The same path every question takes, whichever step you're reading about.
Access & governance

Claude doesn't get its own key.

This is usually the question that decides whether a project like this goes ahead, so it's worth being precise. Claude has no standing access to your data. Every question is evaluated as the person who typed it.

"Show me sales by region for this quarter"
Same question, two people, two different answers
Finance director
North region — returned
South region — returned
Central region — returned
Export region — returned
Every region in the model
Regional manager, South
North region — not returned
South region — returned
Central region — not returned
Export region — not returned
Only the rows their RLS role allows
An illustration of the access model, not a screenshot. The filtering happens inside Power BI before any result is returned, exactly as it does when those two people open the report themselves.
What actually changes

Not a new system. A faster route to the one you have.

Nothing on this list needs a migration, a new licence tier for your warehouse, or a training programme. The reports stay where they are.

Worth knowing first

What this doesn't do.

We'd rather you heard this now than found it in week three. These are real boundaries of the setup, not caveats in small print.

The upside of a narrow first phase is that there is very little that can go wrong. Editing and administration stay a later decision, taken on evidence rather than on hope.

Already in production

We've done this one before.

The integration in that recording is running today across four dashboard areas, for a client whose reports sit on ERP and cloud data. Executives and operational managers use it against live company numbers. The answers get checked against the reports, and they hold up.

Which means the awkward parts, the tenant settings, the Entra registration, the OAuth behaviour that differs from one Microsoft estate to the next, are problems we've worked through once already. That is usually where a first rollout stalls.

What they ask it, day to day, is unglamorous and useful:

Inventory levelsBackordersPurchase orders Stock-outsCustomer accountsCustomer spend Year-over-year product performance

ITL Inventory

Inventory reporting

ICL Inventory

Inventory reporting

Company & Sales

Company and sales reporting

Regional sales

Manager views, filtered by RLS

How we'd run it

Four phases. Each one proves itself before the next.

We don't switch on an AI assistant for a whole company on day one. Each phase ends with something you can check, and nothing moves forward until it holds.

Phase 1 · we start here

Environment review & setup

We review your Power BI estate, confirm the admin access we need, enable the Remote Power BI MCP Server and prepare the Entra registration. Ends when the plumbing is ready for connection testing.

Phase 2

Connect Claude to your models

Claude is connected to the approved semantic models and tested against questions from your real dashboards: inventory, sales, customer spend, backorders. We confirm permissions and RLS still apply through the new route.

Phase 3

Live data & access validation

Testing runs on your live environment rather than a sanitised copy, because you need to check answers against numbers you already trust. We test across roles, including a restricted manager view.

Phase 4

Rollout, documentation, handover

Access extends to the remaining approved users. You get documentation covering the setup, the access process and the key configuration points, plus a walkthrough with your team.

What you're left holding at the end

  • Remote Power BI MCP configuration
  • Entra app registration and OAuth configuration
  • Claude connected to your existing Power BI environment
  • Connection to your existing semantic models
  • Access and RLS validation against your permissions
  • Natural language query testing on your live data
  • Initial rollout for the agreed user group
  • Technical documentation covering the setup, access and key configuration
  • Final walkthrough and handover
Straight answers

The questions we get asked

Does our data leave Power BI?

Your reports and semantic models stay exactly where they are. A question is sent to the relevant model, Power BI evaluates it under the asker's permissions, and the result comes back to be explained. There is no copy of your warehouse sitting somewhere else, and nothing is written back.

Do we need to build a new semantic model first?

No. This connects to the models behind your current reports. Building a new consolidated model is a common and expensive first instinct, and it isn't required here.

What stops someone asking about data they shouldn't see?

The same thing that stops them today. Power BI applies their permissions and Row-Level Security when it evaluates the query, before any result is returned. Claude has no access of its own to fall back on.

Who has to do work on our side?

Your Power BI or Fabric administrator enables the tenant setting, and someone with Entra ID rights helps with the app registration. After that it's mostly us, plus a few of your people to test answers against reports they already know well.

Could we just do this ourselves?

You could. The tenant setting and the app registration are documented, and if you have a Fabric administrator and someone comfortable in Entra ID, it's a reasonable internal project. What you'd be paying us for is having already hit the parts that aren't documented, and knowing what to validate before anyone is let loose on live data.

How current are the answers?

As current as your last successful refresh. Claude reads the most recent refreshed data in Power BI. It isn't querying your source systems directly, and it can't see whether a scheduled refresh failed.

Can it build or change a report for us?

Not in this setup, which is read-only on purpose. Editing reports and administering Power BI Service is a separate piece of work using the Fabric tooling, and it's a decision better taken once the reading side is proven.

How many people can use it?

Start with a small group. In the live deployment it began with the owner and a handful of operational and sales managers. Once the connection and the permissions behave, extending it to more approved users is an access change rather than a new project.

What if our models aren't in good shape?

Then we'll tell you, and we'd suggest fixing that first. Claude reads your model as it is: if a measure is defined wrongly, the answer inherits the error. This works best on top of modelling that's already trusted.

Next step

See it running on your reports.

The most useful thing we can do is spend half an hour looking at what your Power BI estate actually contains, and give you a straight read on what is involved and where the effort actually sits.

Half an hour, no deck. We look at your workspaces and your semantic models.
Bring the question you'd normally have to chase someone for. The fastest way to judge this is to ask it something you already know the answer to, and check.
If your models aren't ready for this yet, we'll say so. We've talked people out of it before.
Founder-led. You'll be talking to the people who'd do the work.
See it on your reports30 minutes, no deck
Book a walkthrough