Co-authored by

Can You Build an Application on Microsoft Fabric?

Quick answer: Yes. Fabric Apps, in public preview since Microsoft Build 2026, hosts a custom-coded web frontend with Entra sign-in and a managed SQL database behind a GraphQL API. Whether it can host your application depends entirely on what that application does when nobody has it open.

Most coverage of Fabric Apps since Build answers a question nobody building software actually asks: what is it? The question that decides a budget is narrower. You have an application — or a proposal to build one — and someone in the room says the analytics platform can host it now. How much of it, exactly?

This post answers that component by component, against Microsoft's own documentation as of 21 July 2026. It is deliberately not a rerun of our breakdown of the four Fabric app capabilities, which separates the Fabric Apps item type from translytical task flows, Power Apps on OneLake, and the Extensibility Toolkit. Read that one if you're still working out which "Fabric app" people mean. This one assumes you know, and asks whether it can carry your build.

What Fabric Apps Actually Gives You

Quick answer: Three managed services — static frontend hosting, Microsoft Entra SSO, and a Fabric SQL database exposed over GraphQL — scaffolded and deployed through an open-source TypeScript SDK called Rayfin.

Microsoft describes a deployed Fabric App as a set of child services:

Three endpoints are exposed: /api/graphql for data, plus /auth and /storage. All data access runs through the generated GraphQL API.

The SDK is real and open source. Rayfin uses a decorator-driven TypeScript model — @entity(), @uuid(), @text(), @role() — to generate the database schema, the GraphQL layer, and a typed RayfinClient from one definition. It ships as npm packages (@microsoft/rayfin-cli, @microsoft/rayfin-core, @microsoft/rayfin-client), and Microsoft's own troubleshooting page points at the public repository for known issues.

One myth worth killing early: this is not a low-code tool, and "it would still be custom code" is not an argument against it. Fabric Apps runs standard frontend code, and the FAQ is explicit that it "works with any frontend framework that can make HTTP requests: React, Vue, Angular, Svelte, Vanilla JavaScript/TypeScript." React with Vite is the default scaffold, not a requirement. The code you'd write here is the code you'd write anywhere.

The Component Test: What Fits and What Doesn't

Quick answer: The frontend and its CRUD layer fit cleanly. Anything that must keep running while no user has the app open has no documented path in Fabric Apps.

Take a working application apart and check each piece against what Microsoft documents:

The wording in that table matters, and it is more careful than most commentary on this topic. I checked the Fabric Apps overview and FAQ for ten terms: WebSocket, SSE, Server-Sent, real-time, background, worker, long-running, cron, scheduled job, and always-on. None of them appear on either page. Not as supported features, and not as stated limitations.

So the honest claim is not "Fabric Apps cannot do these things." It is that Microsoft documents three services — data, auth, and staticHosting — and nothing else, and that a platform which never mentions background execution is not one to bet an always-on requirement on without a written answer from Microsoft. Absence of documentation is not a documented prohibition, and anyone telling you otherwise is filling a gap with confidence rather than evidence.

What Microsoft does commit to is the shape of the thing:

"A Fabric app runs as a managed service in Fabric with a suite of services that define the backend such as app hosting, database, GraphQL APIs, and authentication. Fabric manages the hosting, networking, and scaling."

And a short list of what it isn't for, including "applications requiring complex multi-step transactions or stored procedures."

The practical read: if your application is a user interface over data that lives in Fabric, this is a genuinely good fit and will save you standing up hosting, auth, and a database. If your application has a spine that runs whether or not anyone is looking at it, that spine stays where it is, and Fabric Apps changes where your frontend is hosted rather than what your system is made of.

The Preview Limits That Bite at Design Time

Quick answer: The documented constraints are specific, and several of them land on data modelling decisions you make in week one rather than problems you hit in month six.

From Microsoft's FAQ and troubleshooting pages, as of 21 July 2026:

• No composite primary keys. Entities use a single UUID id.
• No many-to-many relationships. You model an explicit join entity instead.
• No direct SQL. "All data access goes through the generated GraphQL APIs."
• No custom authentication providers beyond Entra SSO and email/password.
• Email and password authentication "doesn't work after deploying to Fabric." Microsoft's wording, not a paraphrase.
• No count() on the fluent GraphQL client — use results.length.
• 100 MB compressed limit on static deployment size.
• No multi-environment management out of the box.

The first two are the ones that hurt. Single-column UUID keys and no native many-to-many are fine if you're greenfield and hear about them on day one. They are expensive if you've modelled a schema around composite keys and discover the constraint after you've written the data layer.

I also could not find a Fabric-Apps-specific service level agreement on any of its documentation pages. The standard Microsoft preview terms apply by reference. For an internal tool that's fine. For anything a regulated buyer will run operations on, "public preview, no product-specific SLA, no published GA date" is the sentence that ends the conversation — and it should, because a preview's limits can move.

Where You Can Actually Deploy It

Quick answer: Fabric App (preview) is regionally patchy, and the Middle East picture in particular is worth checking before you design around it.

Microsoft's region availability page, updated 8 July 2026, lists unavailable features per region. Fabric App (preview) is named as unavailable in more than twenty of them, including UK South, UK West, North Europe, East US, East US 2, Canada Central, Germany West Central, Spain Central, Japan West, and Israel Central.

For teams deploying in the Gulf, three specifics matter:

• UAE Central and Qatar Central are Power BI–only regions. The wider Fabric platform isn't present there at all, so the question of Fabric Apps doesn't arise.
• Israel Central runs full Fabric but excludes Fabric App (preview) by name.
• Saudi Arabia does not appear in the region table at all — that's undocumented rather than documented-as-unavailable, and worth a direct question to your Microsoft account team rather than an assumption either way.

UAE North is not among the regions flagged as excluding Fabric App (preview), which is the closest thing to good news on this list. One caveat on how to read that: the page only enumerates exceptions, and never states a rule that a blank entry means available. Treat UAE North as not excluded rather than confirmed available, and confirm before you commit a design to it.

The page also makes no commitment to expanding preview workloads into more regions. Its only forward-looking line is that "some of the Fabric workloads might not be immediately available in new regions, or regions where data centers become constrained." If you need a region today, plan for today's map.

This is the constraint that catches GCC teams most often, and it's the same shape as the data residency questions that drive Power BI architecture here: the feature exists, the region doesn't, and the gap between those two facts is where a delivery date goes.

Licensing: Cheaper Than Most People Assume

Quick answer: A Fabric App is a non-Power BI Fabric item, so a free Fabric licence on any F capacity is enough to open one. The F64 viewer threshold does not apply.

This is the point most often got wrong in architecture reviews, usually in the direction of overestimating cost. The reasoning goes: users open it through Fabric, Fabric viewer economics require F64 or a Pro licence per head, therefore every operational user needs a paid seat. That chain breaks at the second link.

The F64 free-viewer rule governs Power BI content. A Fabric App is not Power BI content. Per Microsoft's licensing documentation, non-Power BI Fabric items can be viewed by users on a free Fabric licence, provided the workspace sits on Fabric or Trial capacity. If you want the crossover maths for the Power BI side of your estate, that's a separate calculation entirely.

What you do need:

1. The workspace on assigned Fabric capacity.
2. A tenant administrator to enable the Fabric Apps workload — it's off until someone turns it on.
3. "Run and interact" permission on the item for each user. All workspace members get this by default.
4. Every user able to sign in to Fabric via Entra.

That last point is the real coupling, and it's an organisational cost rather than a licensing one. Your operational users need identities in the Fabric tenant and a sign-in that routes through it. For a team already inside Microsoft 365 that's a non-event. For contractors, field staff, or an external agency, it's a provisioning conversation — and it's worth having before you promise anyone a go-live date.

So When Does Fabric Apps Make Sense?

Quick answer: When your application is a governed interface over data that already lives in Fabric, and its failure mode is an inconvenience rather than an incident.

Three cases where it earns its place today:

• Internal tools around your data estate. Reference-data editors, configuration screens, small approval workflows. These are exactly the applications nobody wants to build because standing up hosting, auth, and a database costs more than the tool is worth. Fabric Apps removes that overhead.
• Data-entry surfaces feeding the analytics you already run. Manual adjustments, forecast overrides, mapping tables — the spreadsheets that quietly became production systems.
• Prototypes that need real auth. Anything where you'd otherwise fake sign-in to demo a concept.

And the cases to keep out of it, for now: anything with an always-on requirement, anything a regulator or an operations team depends on while it's in preview without a product-specific SLA, and anything that has to run in a region where the workload isn't listed.

The strategic point is that this decision is cheap to defer and expensive to rush. Fabric Apps is in preview, its limits are documented and moving, and the architecture that keeps your ingestion and always-on components as Azure services can adopt Fabric Apps for the frontend later without a redesign. Adopting it late costs almost nothing. Adopting it early, for a system that needed the pieces it doesn't document, costs the build.

Re-check it quarterly. The preview limitations list is the thing to watch, not the announcement.

Frequently Asked Questions

Q: Is Microsoft Fabric Apps generally available?

No. As of 21 July 2026 it is in public preview. Microsoft's documentation page is titled "What is Fabric Apps (Preview)?" and states "This feature is in preview." It was introduced at Microsoft Build 2026, with documentation dated 2 June 2026. No general availability date has been published, and no Fabric-Apps-specific SLA appears on its documentation.

Q: Can a Fabric App be opened outside the Fabric portal?

Generally yes. A deployed app gets a public URL of the form https://<your-app>-app.rayfin.windows.net/, with Fabric SSO required to reach it. There is one documented exception: apps built from the data-app template and connected to a Power BI semantic model currently "can't be opened in their own browser window outside the Fabric portal," and Microsoft describes that as "a temporary limitation, and will be addressed in a future release."

Q: Do users need a Power BI Pro licence to open a Fabric App?

No. A Fabric App is a non-Power BI Fabric item, and those can be opened by users holding a free Fabric licence as long as the workspace is on Fabric or Trial capacity. The F64 threshold that governs free viewing of Power BI reports doesn't apply. Users do need "Run and interact" permission on the item and the ability to sign in to Fabric through Microsoft Entra.

Q: Can Fabric Apps replace a custom web application?

It depends on what the application does besides render an interface. Fabric Apps documents frontend hosting, Entra authentication, and a Fabric SQL database behind GraphQL. It does not document background workers, scheduled jobs, persistent connections, or streaming — those terms appear nowhere in its overview or FAQ. If your application is a UI over Fabric-resident data, it can carry the whole thing. If your application has components that run continuously, those stay as Azure services and Fabric Apps changes only where the frontend is hosted.

Q: Is Fabric Apps available in the UAE and Saudi Arabia?

UAE North is not listed among the regions that exclude Fabric App (preview) on Microsoft's region availability page, updated 8 July 2026. UAE Central and Qatar Central are Power BI–only regions where the broader Fabric platform isn't available. Saudi Arabia does not appear in that region table at all. Because the page enumerates only exceptions and never states that a blank entry means supported, confirm availability with Microsoft before committing an architecture to a specific region.

Q: What is Rayfin?

Rayfin is the open-source TypeScript SDK behind Fabric Apps. It uses decorators such as @entity() and @uuid() to generate a database schema, GraphQL API, and typed client from a single data model definition. It ships as the npm packages @microsoft/rayfin-cli, @microsoft/rayfin-core, and @microsoft/rayfin-client, and its source is public at github.com/microsoft/project-rayfin.

Deciding where an application ends and analytics begins is the architecture question underneath most Fabric conversations, and it rarely gets settled by a feature list. Beyond The Analytics builds Power BI and Fabric platforms for UAE and Saudi enterprises, including the awkward cases where a dashboard isn't the answer. If you're weighing a build like this, the Fabric versus Power BI decision framework is the companion piece to this one.