Fabric Apps Public preview

Tool-belt series · Microsoft Fabric · Application layer

Fabric stopped being
a data platform and became an application platform.

Fabric Apps is a first-class workspace item for building real web applications on top of your Fabric data — with Entra sign-in, managed hosting and a backend provisioned for you. It closes the two gaps the BI stack never covered: writing data back, and interfaces that aren't a report. This is the short orientation to read before you get access.

Status — read this first

Fabric Apps went to public preview on 2 June 2026, announced at Microsoft Build. Preview means the shape is real but the details will move: expect API changes, gaps in ALM, and licensing that isn't fully settled. Don't put a month-end process on it yet.

What preview is genuinely good for: learning the model now, so that when it reaches your tenant you're the person who already knows what it replaces and what it doesn't.

01

What it actually is

Not a report. Not a Power App. A hosted web application that is a Fabric item — living in a workspace, governed by workspace permissions, versioned like everything else.

The one-paragraph version

You build a browser-based application. Fabric hosts it as a managed service, provisions its backend, wires up Entra ID authentication so users sign in with their work account, and gives it governed access to your data. No web server to run, no embed tokens to mint, no separate app registration to babysit, no App Service to pay for and patch. The app is an item in a workspace — so the same roles, the same Git integration, and the same governance that cover your lakehouses cover your app.

That last point is the one that matters strategically. Every previous "let's build a small app on our data" story meant leaving the data platform and taking on a second stack. This keeps it in one place, under one permission model.

Why this existsFabric's arc is fairly legible: an analytics platform in 2023, a data platform in 2024 when SQL database arrived, an intelligent platform in 2025 with Copilot and data agents — and an application platform in 2026 with Apps. Each step absorbed a thing organisations were previously buying separately.
02

Two flavours — and they solve different problems

Fabric Apps ships as templates. The two that matter are operational apps and data apps. Confusing them is the easiest way to pick the wrong tool.

Operational appwrite

The default template. A transactional, write-enabled application with its own managed SQL database provisioned as a child item, exposed through a GraphQL API.

  • Built for: planning cycles, master-data maintenance, approvals, forecast entry, any decision loop where a human puts data in.
  • Replaces: the Power Apps + Power Automate + Dataverse stack teams reach for when Power BI can't write back.
  • Key trait: its SQL backend mirrors into OneLake, so what users enter is immediately analysable next to everything else.

Data appread

A code-first, visualisation-focused application that queries published semantic models using DAX and renders whatever interface you want.

  • Built for: interactive experiences that exceed what a Power BI report can express — custom interactions, bespoke visuals, unusual navigation.
  • Escapes: the one-model-per-report ceiling — a data app can query across several semantic models.
  • Key trait: it reuses your existing semantic model, so your measures, RLS and business logic still apply. You are not rebuilding the model.
The distinction in one lineOperational app = people put data in. Data app = people get data out, in a shape a report can't do. If someone types a number and expects it saved, that's operational.
03

How the pieces fit

Worth carrying this picture in your head — it's what makes the licensing and governance questions answerable.

User signs in with Entra Fabric App a workspace item • managed static hosting • Entra ID built in • workspace permissions GraphQL DAX Managed SQL database child item · operational apps · writes Semantic model data apps · your measures & RLS OneLake everything mirrors back to one store no web server · no embed tokens · no separate app registration · no App Service bill — it is a Fabric item

Note: drawn from Microsoft's Build 2026 announcement and public preview write-ups — an orientation diagram, not an official architecture reference.

Rayfin — the developer side

Alongside Apps, Microsoft published Rayfin, an open-source SDK and CLI for defining and deploying app backends. It's the code-first path: developers — and AI coding agents — declare the backend, and Fabric provisions it with enterprise security and governance attached from the start.

The interesting implication is that Apps is deliberately designed to be built by agents, not only by hand. If you already drive Copilot or Claude over a codebase, that skill transfers directly here.

04

When to use it — and when not to

The value of knowing this early is being able to say "no, that's a report" or "no, that's a Power App" with confidence, instead of building the wrong thing enthusiastically.

If you need…UseBecause
A dashboard people readPower BI reportFaster to build, easier to govern, and everyone already knows how to consume it. Don't build an app to redraw a bar chart.
An interactive experience a report can't expressData appCustom interaction and layout, over multiple semantic models, reusing your existing measures and RLS.
Users to enter or correct dataOperational appReal write-back with its own SQL backend that mirrors into OneLake — no Dataverse, no second platform.
A simple form for a handful of peoplePower Apps (for now)Mature, low-code, well understood. Fabric Apps is preview and is code-first — use it where its strengths matter.
Analytics embedded in an existing productPower BI EmbeddedFabric Apps assumes users sign in with Entra to a Fabric-hosted app; it isn't a drop-in embed story for external customers.
A question answered in EnglishData agentCheaper and faster than any UI you'd build for the same purpose.
Preview cautionsLicensing and capacity consumption for Apps are still settling — a hosted, always-available app is a different consumption profile from a report someone opens twice a week. Confirm the cost model with whoever owns your capacity before anything goes near production, and expect the ALM story (Git, deployment pipelines) to firm up over the preview.
05

What to do before you get access

All of this is useful whether Apps lands next month or next quarter — and it's what makes your first app take a day instead of a fortnight.

  1. Write down the write-back problem you already have

    Every finance and operations team has one: a spreadsheet of adjustments, a forecast entry file, a mapping table someone maintains by hand and emails round. That's your first operational app, and you can identify it today.

  2. Get the semantic model right first

    A data app queries your model with DAX. If the measures are inconsistent or the model is a flat table, the app inherits every one of those problems. Gold-layer modelling is the prerequisite, not an afterthought.

  3. Learn the GraphQL API in Fabric now

    It's already generally available independent of Apps, and it's the same access path an operational app uses. Building one API over a lakehouse this month means the app layer is the only new thing to learn later.

  4. Decide who owns apps in your organisation

    An app is software: it needs an owner, a support route and a lifecycle. The teams that struggle with Apps will be the ones who treated it like a report. Raise this before the first one ships, not after.

  5. Watch the monthly Fabric feature summaries

    Preview features change fast. Fifteen minutes a month on the Fabric blog keeps you the best-informed person in the room on this — which is most of what being the expert consists of.

The positioning line worth having ready"Fabric Apps means we can build the write-back piece without standing up a second platform — same data, same permissions, same governance." That sentence is the whole business case, and it lands with both IT and finance.
← back to the tool belt