Microsoft Fabric Apps in the Wild: What's Confirmed So Far
Your Power BI reports show the team what's happening. But the moment someone needs to act on it, whether that's adjusting a forecast, flagging an account, or correcting a target, they leave the report for a spreadsheet, an email thread, or a separate app. Fabric Apps is Microsoft's attempt to close that gap for the moments when a dashboard isn't enough: applications built directly on Microsoft Fabric, next to the data your reports already use.
As of October 2026, Fabric Apps is still in preview, and Microsoft has kept documenting it in public as it moves. Here's what's actually confirmed today about how it works and where early interest is showing up, based on Microsoft's own documentation rather than early impressions.
The Platform Underneath: The Rayfin SDK
Fabric Apps is built on the Rayfin SDK. Instead of building a database and an API by hand, developers describe what the app's data looks like in TypeScript, and the platform generates the database (a SQL database in Fabric) and a GraphQL API from that description automatically. In practice, that description is a set of TypeScript classes marked with decorators such as @entity() and @text(). The client side checks that every request matches what the backend expects before it's sent, which catches mistakes early instead of letting them show up later in production.
Permissions work the same way: who's allowed to see what is defined right alongside the data itself, through row-level security rules set with @role decorators, not bolted on separately in the app's screens. Authentication runs through Fabric's existing single sign-on, backed by Microsoft Entra ID, so there's no separate login system to build. Once an app is deployed, Fabric SSO is the only sign-in option. Local development can fall back to a simple email and password, so developers aren't blocked on SSO setup just to iterate.
What Deploying a Fabric App Looks Like
The workflow is scaffold, build, deploy. A project starts from the Rayfin CLI (npm create @microsoft/rayfin@latest), gets built and tested locally with Docker, and ships with a single command: npx rayfin up. That command provisions the backend, applies the database schema from your code, and publishes the frontend's files to a public URL.
Each deployed app gets one base URL that exposes everything it needs: the GraphQL data API, authentication, and file storage. Microsoft's documentation is also explicit that the underlying SQL database is read-only from the Fabric portal. Schema changes have to come from a code deployment, not a manual edit, and Microsoft warns that changing the schema directly in the database can break the app. That's a deliberate constraint: it keeps the app's data model as a versioned artifact instead of something that can drift out of sync with the code.
The Template Built Specifically for Reporting Teams
Alongside the general-purpose Rayfin workflow, Microsoft documents a second path aimed squarely at BI teams: a data-app template that connects directly to an existing Power BI semantic model, with authentication, DAX query generation, and chart components included out of the box. This is the piece that matters most for teams already living in Power BI. It's not a from-scratch app. It's a template that assumes you already have a semantic model and want a writable layer next to it, so the measures and relationships your team has already built keep doing the work.
What Responsibility Stays with the Developer
Microsoft's documentation is direct about where the platform's guarantees end. Fabric handles SSO, HTTPS, PKCE (a standard safeguard that keeps intercepted sign-in codes from being reused), row-level security, and workspace- and item-level permissions. What it doesn't do is keep secrets out of your code: static frontend assets are served from a public URL, so anything hardcoded there is public. Microsoft's guidance is to keep secrets, API keys, and sensitive data out of frontend assets regardless of how hosting access is configured. Developers are also responsible for three more things: what an authenticated user can see and do once signed in, scoping deployment permissions to only the contributors who need them, and the legal and compliance side of whatever data the app collects.
Where the Real Interest Is Showing Up
Fabric Apps launched into preview with community activity following quickly: independent walkthroughs from BI-focused creators, including a hands-on build using GitHub Copilot to scaffold an app, and explainer content aimed specifically at Power BI practitioners. That's a reasonable signal for a preview feature: adoption by people who build data tools for a living, ahead of official case studies.
What's Still Open
Two things are worth tracking as the preview matures. First, regional availability is partial today, so check your tenant's region against Microsoft's region availability list before planning a rollout. Second, there's no public case study yet from Microsoft naming specific organizations running Fabric Apps in production. What exists so far is documentation, community tutorials, and early builds, including one of our own: an operational console for a client that took about a day end to end. That's normal for a preview, but it means claims about production-scale usage should wait for Microsoft's own case studies rather than be inferred from the docs.
The Bottom Line
Fabric Apps gives developers a code-first way to put a working app next to the data your team already trusts, with sign-in, permissions, and deployment handled by the platform. It's still early, so the practical move today is to evaluate it on one contained, non-critical use case and keep an eye on regional availability and Microsoft's first case studies.
Considering a Fabric App on top of your Power BI semantic models? We're happy to walk through a first use case with you and check your region and permissions before you build.
Talk to Us About Evaluating Fabric Apps for Your Workspace.
Written by Florencia Rottoli
Project Manager