Every conversation about Power BI outside Power BI starts the same way. Someone wants "the dashboard inside the portal": on the intranet, in SharePoint, with the company colors, without that iframe giving away that the report lives somewhere else. The tech team opens the docs, finds Embedded, dedicated capacities, tokens, and within half an hour the meeting is already discussing a monthly subscription nobody had budgeted for.
We went through that script recently. We analyzed the existing report, cross-checked it with the client's list of improvements, and designed the architecture, the model and the estimate. Halfway through, one simple question reshuffled everything: who, in the end, is going to look at these numbers?
The answer was: very few people. A small team that uses the dashboard to build a fixed PowerPoint report sent to the business areas. That changed the architecture, the licensing and even the role of AI in the project. Let's take it step by step.
Five doors to take Power BI out of Power BI
There are basically five ways to bring Power BI content into a web page, and they are not variations of the same thing:
| Path | Who sees it | Viewer license | Visual control |
|---|---|---|---|
| Publish to web | Anyone with the link | None | None, and the data is public |
| Secure embed | Users in the organization | Pro or PPU | Iframe, no code |
| Embed for your organization | Users in the organization | Pro or PPU | Iframe controlled by JavaScript |
| Embed for your customers | External users | None (you pay for capacity) | Iframe controlled by JavaScript |
| Execute Queries API | Whoever your app authenticates | Pro or PPU | Full: you draw it |
The first four share one thing: what appears on screen is an iframe served by app.powerbi.com. You can filter, switch pages and capture events through the SDK, but your portal's CSS does not get in there. If the requirement is "it should look native", the fifth door is what remains: ask for the numbers and draw them yourself.
The API that returns numbers, not reports
The Execute Queries API takes a DAX query and returns rows as JSON. Inside a SPFx web part, the token comes from the user's own Microsoft 365 session, with the Dataset.Read.All permission. The query runs with the identity of whoever opened the page, and the model's row-level security applies without any extra backend.
The limits need to be on the table from day one:
- one query and one table per call;
- at most 100,000 rows or 1 million values per query;
- 15 MB per response;
- 120 queries per minute per user.
It is an API for KPIs and aggregated tables, not for bulk extraction. And it has a catch: if a query goes over the limit, the response comes back with HTTP 200 and partial data. The status says everything went fine. The error is hidden inside the JSON.
When there is no report in the middle, the semantic model becomes a contract. Renaming a measure now breaks a screen.
The model that only worked because nobody looked closely
The model we found made the report work, but it had been built around the visuals, not as a data source. People tables with no relationship to the events table. Calculated columns fetching attributes row by row. The same email normalization repeated across a dozen measures. Automatic date tables hidden everywhere.
Inside Power BI, the visuals hide all of that. Through the API, every shortcut turns into a slow query, a mismatched number or a measure you cannot filter. So the migration is not "swap the screen": it is refactoring the model into a star schema, creating explicit measures in a folder dedicated to the API and validating the numbers, KPI by KPI, against the old report.
A tip that saves hours: Power BI Desktop's Performance Analyzer shows the exact DAX query behind each visual. It is the perfect starting point for the web part's query catalog.
The license nobody needed to buy
This is where "who is going to look?" mattered most. Power BI Pro costs US$14 per user per month since April 2025. A Fabric F64 capacity lets users with a free license view content, but it costs close to US$5,000 per month on a one-year reservation. The math only works when hundreds of people consume the content.
For a small team, the math is different: a handful of Pro licenses, or no extra cost at all if people already have Microsoft 365 E5. And the areas that receive the report never open Power BI; they get a file. (It is always worth confirming this distribution model with your licensing partner.)
That also changes how you export. Native automated export to PowerPoint (ExportToFile) requires dedicated capacity. But the web part already holds each query's data in memory, and a library like PptxGenJS builds the .pptx right in the browser, with native, editable charts and the company's visual template. The "Export to PowerPoint" button costs development hours, not a subscription.
Fabric: present everywhere, required almost nowhere
Today Power BI is one of the workloads of Microsoft Fabric. Workspaces, models and tenant settings already live in the Fabric portal, even for teams who think they "don't use Fabric". Still, nothing in this architecture required Fabric capacity: the API works with a Pro license on shared capacity.
Where it did make sense was an unexpected place: the portal's telemetry. Navigation events were being written to a SharePoint list that was already piling up tens of thousands of items per month. The client wanted to measure time on page, which multiplies that volume. A list is not built for that. For that specific case, an F2 capacity, the smallest in the family, with Eventstream or a Lakehouse is the honest answer.
When AI enters the timesheet
Microsoft released the Power BI Authoring MCP, still in preview: a server that lets an AI agent create tables, measures, relationships and security roles in natural language, working on PBIP files versioned in Git and running DAX to validate the result. It does not create visuals, which in this project did not matter: the visuals lived in SPFx.
With AI in the model, in the web part code and in classifying the chatbot's topics, the estimate dropped by about 40%. But you have to be honest about where those savings live. The evidence is mixed: a GitHub experiment measured developers 55% faster on an isolated task, while a 2025 METR study found experienced developers 19% slower working on code they already knew.
| Speeds up a lot | Barely speeds up |
|---|---|
| DAX measures and model refactoring | Client answers |
| Web part components and services | User acceptance and number reconciliation |
| Generating the PowerPoint | Approving permissions and access |
| Topic dictionary built from thousands of messages | Waiting for the new telemetry to collect data |
AI shortens the build. The project clock is still, to a large extent, the people's clock.
Before you sign, ask who is going to look
The right architecture did not come from comparing SKUs or reading feature lists. It came from a question about people: how many will see this, and what do they do next. A few people building a report for the business areas do not need dedicated capacity; they need a clean model, a well-used API and a button that produces the monthly PowerPoint.
Before discussing licenses, ask who is on the other side of the screen. Very often the answer is an email with a .pptx attached.
If you enjoy this kind of behind-the-scenes story, with real numbers and no hype, subscribe to the macareno.net newsletter and get the next articles first.
Sources
- Datasets - Execute Queries (REST API), Microsoft Learn
- Understand Microsoft Fabric licenses and capacity, Microsoft Learn
- Power BI Authoring MCP server, Microsoft Learn
- Publish to web from Power BI, Microsoft Learn
- Power BI Licensing & Pricing 2026, Zebra BI
- The Impact of AI on Developer Productivity: Evidence from GitHub Copilot, arXiv
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, METR