What Microsoft Fabric Apps unlocked for me (and why I am writing about it)

Przemysław Kujda — Thu, 16 Jul 2026 13:05:30 +0000

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

DEV Community: Przemysław Kujda