The latest wave of Microsoft Fabric updates made a strong impression on me. Not because of another feature checkbox on a roadmap, but because it became clear that Fabric is no longer "just" a platform for warehouses, pipelines, and notebooks.
It is becoming a place where you can ship real analytical applications that feel like products, not only reports.
That realization is why I decided to write this article, and why I started building my first Fabric App.
This is still an early version of the work. I am learning the surface area of Fabric Apps as I go, and I am sure that with deeper exploration we will be able to build even stronger solutions. Even at this stage, though, the pattern already feels powerful enough to share.
What Fabric Apps give us
For a long time, if you wanted a custom analytics experience (not only Power BI pages, but also your own UI, navigation, workflows, and AI copilots), you often ended up designing a full-stack product:
- frontend
- backend
- authentication
- APIs
- hosting
- permission plumbing
That path still works. It is also heavy.
Fabric Apps change the trade-off.
Because the experience lives on Fabric and can talk to your semantic model (and other Fabric capabilities) through the platform, you can focus much more on the frontend layer: the product surface your users actually touch. You do not need to reinvent an entire backend just to answer a business question.
In practice, that means:
- one shared semantic model as the source of truth
- the ability to combine native Power BI visuals with custom React interfaces
- room for UX patterns that classic report pages do not express well: guided navigation, AI chat, storytelling, interactive showcases
This feels less like "publishing a report" and more like delivering a product: one connected experience, built on a single source of truth, tailored to the business case.
Why this matters for reporting
To make that concrete, here is how I think about the split:
| Situation | Recommended surface |
|---|---|
| Existing Power BI report already works well | Embed native report inside the app |
| Users need guided navigation or onboarding | Build a custom React page |
| AI Q&A or conversational interface | Custom page with semantic model queries |
| Operational briefing for non-analyst users | Custom page with curated KPIs |
| Ad-hoc exploration by analysts | Native Power BI report |
The interesting part is the mix:
- where Power BI is already excellent → embed the native report
- where the experience needs to feel more like a product → build a custom page
- and everywhere → keep both sides connected to the same semantic model
Depending on the business case, you choose the right surface, without splitting the truth across multiple disconnected systems.
That is what excited me most: Fabric Apps make this hybrid model feel natural.
What I built (first version)
I built a multi-page Fabric App around a Sales & Logistics semantic model.
Below is a walkthrough of the modules. I will keep this high-level for now. If useful, I can go deeper on specific capabilities in follow-up posts.
1) Home: the entry point
A launchpad that introduces the experience and routes users into each module.
2) Custom Dashboard: live semantic-model analytics
A custom React dashboard that queries the Fabric semantic model directly:
- KPI cards
- monthly trends
- customer ranking with cross-filtering
- logistics views
- CSV export
- auto-generated "quick insights"
This is the hand-built product UI side of Fabric Apps — a custom React layer querying the semantic model directly via the Fabric REST API, but sharing the same business logic as the native reports. No duplicated measures, no separate data source.
Implementation note: querying the semantic model
const result = await getFabricClient()
.semanticModel("model")
.query(dax, { bypassCache: true });
KPIs and charts are driven by live queries against the Fabric semantic model.
3) Native Power BI Reports: chromeless Power BI inside the app
A native Power BI report embedded inside the app (without the usual chrome), with page selection for the pages we want users to see.
This shows the complementary pattern: keep strong Power BI work where it already shines, and deliver it inside the same app shell.
4) AI Assistant: questions against real numbers
An AI analyst that answers questions about KPIs and trends using results computed from the semantic model.
It also adapts to the language of the question (English or Polish).
One design choice that shaped the whole assistant: the AI does not freely generate DAX for every question.
The pattern I used instead:
- A set of pre-defined, safe queries covers the core KPIs and trends
- The language model receives the computed results (not raw data) and interprets them in natural language
- Only for questions outside that scope does the assistant fall back to a templated response
Why does this matter? Letting an LLM generate arbitrary DAX looks impressive in a demo and breaks in production. Computed metrics first, language last — that order makes the assistant actually usable outside a controlled environment.
Implementation note: keeping AI grounded in real numbers
const metrics = await fetchCoreMetrics();
return generateGeminiText({
userPrompt: buildPrompt(question, metrics),
});
Safe queries first, language model only for the answer.
5) Product Showcase and Visual Lab: what custom UX can feel like
Two showcase pages focused on interaction and visualization (mock data on purpose):
- product drill-down panels
- animated charts
- KPI rings
- heatmaps
- other custom visuals
These pages are a proof of concept for one idea: the UI ceiling in Fabric Apps is much higher than in classic Power BI. Animated charts, KPI rings, drill-down panels — all of it is standard React, which means you are not limited to what the Power BI visual marketplace offers.
A note on tools (and Cursor)
Even with React experience, building this kind of app still involves a lot of moving parts:
- layout and navigation
- embedding and tokens
- semantic-model querying
- UX polish
- iteration speed
Cursor made a huge difference.
From shaping the report layout and page structure to implementing features and debugging edge cases, it significantly accelerated the work.
The areas where it helped most: scaffolding the React component structure, debugging token and embedding errors, and iterating on layout without losing context across files.
For me, it is not a replacement for understanding the stack — it is a force multiplier, especially when the platform itself is still evolving fast.
This is only the beginning
Everything above is a first version. The more I dig into Fabric Apps, the clearer it becomes that this is a foundation for richer solutions — still with the same core idea: frontend-first delivery on top of Fabric.
This is still an early build. The next post will go deeper on one specific capability — most likely the semantic model querying pattern from the React side.
If you are exploring Fabric Apps, Power BI embedding, or AI copilots on top of a semantic model — drop a comment. I would love to hear what you are building.
💻 GitHub repository: https://github.com/przemq99/first-fabric-app
Top comments (0)