Do you need Fabric? When it wins, and when you are better off building yourself

Short answer: if you want a custom dashboard on top of a Power BI model that already exists, and your people work in Microsoft 365, a Fabric App is a good choice. If you are building an application where people enter data themselves, with users who have no Microsoft account or with data from external systems, you are better off building it yourself today.

The difference is not in how good Fabric is. It is in what kind of app you are building.

A view is something else than a source

Fabric Apps come in two kinds, as described in the news overview. A data app reads an existing Power BI model. An operational app has its own database and can write data back.

A data app is a view of data that has already been modelled. An operational app is the source itself. A schedule does not exist until someone drags a bar.

Almost everything you read about Fabric Apps today is about the first: measures moving into the app, DAX per chart, row-level security that keeps applying. That is all true, and it does not touch the second at all.

From that follows something you will not read in most reports. If apps come to Power BI Pro, that changes the story for dashboards. For operational apps it changes little, because there the capacity is not the obstacle.

A planning board that cannot be a Fabric App today

A concrete example. At a contractor we built a planning board: a calendar in which the office drags job sites to crews and days. It runs on Vercel, with a Postgres database at Neon, and it was written with an AI agent. The app also contains an AI assistant that proposes schedules and pulls material lists out of quotes. The office confirms. The AI never writes anything away itself.

The planning board shares one database with two other apps of the same company, and fetches quotes live from the invoicing package. How that went so fast is in the third app was the fastest.

For three reasons this cannot be a Fabric App today.

The login. The board deliberately has one shared code for the office, because it does not know individual people. Why is in nobody types a password on a roof. Fabric Apps work exclusively with Entra ID. So everyone who looks needs an account in the company's Microsoft environment, and which licence goes with that is still an open question. There is also no way to show the app on your own site without a Microsoft login.

The region. A Belgian company whose Microsoft environment sits in Belgium Central cannot use Fabric: that region is Power BI-only.

The connections. The data already sits in a shared Postgres database and partly comes live from an external API. In Fabric it first has to be brought in, and you cannot connect an existing database as the app database. The schema comes from the app's own code.

Each of those three is a reason on its own. Together they make the choice simple.

At Microsoft, the AI is in the building, not in the product

Another distinction that often gets mixed up. With Fabric Apps the AI is in the building: an agent writes the app. An AI feature in the product itself, like the assistant that pulls a material list out of a quote, you have to build yourself in Fabric just the same.

That assistant is a good example of how fast this moves. When we first looked at the quotes, a quote turned out to be one block of running text. With a fixed rule nothing could be extracted from it. With AI it can, provided a person checks the result.

Where Fabric does win

The reverse is just as true, and it happens more often than you think.

• There is already a model with years of work in it. Measures, relationships, row-level security. Then you reuse all of it and only build the front end. That is exactly what a data app is made for.
• Your people already work in Microsoft 365. Then signing in through Entra is an advantage, not a limitation. No shared code on a note next to the screen, and whoever leaves the company automatically loses access.
• You want governance. Who sees what, who looked at what, and the app distributed next to the existing reports. Microsoft already has that built in.
• You do not want to manage hosting, login and database yourself. With your own stack, you or your partner are responsible for that. In Fabric, Microsoft does it.

For a dashboard on an existing model, for people who already work in Microsoft 365, in a region where it is available, a data app is often the simplest route.

Where building yourself wins

• As soon as the app becomes operational instead of analytical: people enter data, and the app is the source.
• As soon as people without a Microsoft account need to use it: crews, customers, suppliers.
• As soon as external systems come into play that are queried live.
• As soon as the app has to sit on your own site.

Which stack of your own is a separate question. We chose Postgres at Neon; why is in Neon or Supabase.

What can still change

Everything above is a snapshot. Fabric Apps are in preview, without an availability guarantee, and features and licences can still change. If apps come to Pro as announced, the capacity threshold disappears for many smaller companies. Then the data app becomes a lot more attractive for dashboards.

But the login, the region and the connections have nothing to do with capacity. As long as those do not change, the story for operational apps stays the same.

What you can automate

Two of the questions below can be answered automatically. You can query the region of a Microsoft environment and the available capacity through the Fabric API, and read through the Admin API whether the required settings are switched on. Then you know before the first conversation whether Fabric is technically an option.

The claim

Ask four questions, in this order. Is the app a view and not a source? Do all users work in Microsoft 365? Is your environment in a region with Fabric? Is the data already in a Power BI model? Four times yes: take a data app. Is the app a source, or do people without a Microsoft account need it: build it yourself. Does only the region fail: then Fabric is not an option today. Is there no model yet: then you start with the model, and that question has nothing to do with Fabric.