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, re-checked and corrected on 29 July 2026 against apps we have since deployed. 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.

It also assumes the build is warranted. If that part is still open, when to use Power BI vs a custom application settles it first — half of what teams scope as an application turns out to be a report.

Fabric Apps Services: Database, Auth, and Hosting

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 on the app's backend URL: /api/graphql for data, plus /auth and /storage. All data access runs through the generated GraphQL API.

Where GraphQL sits in that picture is worth pinning down, because Microsoft's own pages disagree with each other. The child-service table above has three rows and no GraphQL entry — the generated API is a path on the backend endpoint rather than a separate child item you manage. But the same overview page describes the app in prose as "a suite of services that define the backend such as app hosting, database, GraphQL APIs, and authentication," which reads as four. Design against the table. The API is generated from your data model, not provisioned alongside it.

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 the source is public at github.com/microsoft/rayfin. Microsoft's own troubleshooting page points at a microsoft/project-rayfin repository for known issues, which 404s — a small thing, but a fair indicator of how fresh this documentation set is.

Fabric Apps Templates: SQL Database vs Semantic Model

One thing the service tables above don't tell you: there are two templates, and they are not variations on a theme. They are different data architectures, and picking the wrong one is a rebuild rather than a refactor.

That write column is the one to sit with. If your app needs to capture anything — an override, an approval, a mapping correction — the semantic-model template has nowhere to put it. You can read live model data and render it beautifully, and you cannot accept a single keystroke back. Teams reach for dataapp because they already have the model and it feels like the shortcut, then discover the requirement they actually had was write-back.

For a BI estate this is the more interesting template, and it's the one most coverage skips entirely. Microsoft's own page for it is worth reading before you choose.

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.

What Fabric Apps Can and Can't Host

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.

What a Custom Web App Gives You Instead

Quick answer: Roughly four Azure services and the operational work of owning them — in exchange for everything on the "not documented" side of that table, plus a GA-level SLA and any region you like.

A comparison is only useful if both sides are priced, so here is the thing Fabric Apps is being compared to. Build the same application yourself on Azure and the shape is familiar:

What that buys you is precisely the column Fabric Apps leaves blank: continuous ingestion, scheduled jobs, always-on evaluation loops, server-push to connected browsers. Plus composite primary keys, native many-to-many, stored procedures, direct SQL, non-Microsoft identity providers, a published SLA you can put in a contract, and deployment into any region Azure offers rather than the subset where a preview workload has landed.

What it costs you is the part teams routinely underestimate: you now own the hosting, the auth wiring, the database, the CI/CD, the patching, the certificate renewals, the monitoring, and the person who gets paged. For a genuinely small internal tool that overhead can exceed the value of the tool — which is exactly the gap Fabric Apps is aimed at, and why "we'd just build it ourselves" is not automatically the cheaper answer.

The honest summary is that this is not a like-for-like contest. Fabric Apps trades away control and always-on capability for the removal of nearly all setup. A custom build trades setup and ownership for the ability to do anything. The interesting question is never which is better — it's which set of constraints your specific application can live inside.

Fabric Apps Preview Limitations

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 from the application. "All data access goes through the generated GraphQL APIs." A connection string to the underlying Fabric SQL database does exist — the FAQ says you "can also connect directly to the SQL database if you have the connection string," and the portal ships a query editor — but that is a read and export path, not a way to widen what the app itself can do. The portal's copy of the database is read-only, and Microsoft warns that schema changed directly in SQL is overwritten on the next rayfin up and "can break the app."
• 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.

Fabric Apps Region Availability in the Gulf

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), and here we can go further than the page itself allows: we have Fabric Apps deployed and running in UAE North, on hosting URLs that carry the region in the hostname. That is the closest thing to good news on this list, and it is firsthand rather than inferred.

It needs saying that way because the region page enumerates only exceptions, and never states a rule that a blank entry means available. For any region you haven't deployed into yourself, treat a blank entry 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.

Fabric Apps Licensing: Do You Need Power BI Pro?

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.

When to Use Fabric Apps vs a Custom Web App

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, and it is worth being precise about which URL you get, because a deployed app has two of them and they are different hosts.

The App backend URL is the one Microsoft publishes a format for — https://<your-app>-app.rayfin.windows.net/ — and it is the base for /api/graphql, /auth, and /storage. The App URL is the one a person actually opens. Microsoft's documentation confirms both properties exist and describes what each is for, but never publishes the App URL's format. In the apps we have deployed it takes the shape https://<name>-<hash>-<region>.webapp.fabricapps.net — a UAE North app resolves to a ...-uaenorth.webapp.fabricapps.net hostname. Fabric SSO is required either way.

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.

The custom equivalent it replaces is roughly Azure Static Web Apps or App Service, Entra via MSAL, and Azure SQL — four services and the work of owning them. Fabric Apps removes nearly all of that setup and takes away always-on execution, non-Microsoft identity providers, composite keys, stored procedures, direct SQL, a published SLA, and any region outside the preview's footprint. Whether that trade works is an application-by-application question, not a platform verdict.

Q: Can a Fabric App write data back to a Power BI semantic model?

No. An app built from the dataapp template reads its semantic model through the Execute DAX Queries REST API, which is a query interface with no write path — so there is nowhere for user input to go. If your application needs to capture overrides, approvals, or corrections, use the default template's managed Fabric SQL database, which you can write to through generated GraphQL mutations. This is the distinction that decides which template you start from, and it is not reversible cheaply.

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

UAE North works — we have Fabric Apps deployed and running there, and it 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 any region you haven't deployed into yourself.

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/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.