What Fabric Data Apps Change (And What They Don't)

Fabric data apps let you build reporting entirely in code. Here is what that really gives you, what it quietly takes back, and who should care.

Fabric data apps give you control of every pixel on the canvas. The catch is that performance, accessibility, consistency and maintenance become your problem, not the platform's.

In practice, this is where our Microsoft Fabric delivery comes in, and Qlik To Power BI: Lessons Learned The Hard Way covers useful related ground.

For years, the limits of the Power BI canvas were the job. You wanted a chart shaped a certain way, and the tool said no, so you found a workaround or you let the requirement go. That constraint is now lifting. Fabric data apps let you build a dashboard entirely in code, query your semantic model in DAX, and render visuals with libraries like Vega-Lite or D3. If you can specify it, you can build it.

This is a real shift, and it is worth understanding properly rather than from a screenshot. It is also not the thing most of the excited posts make it out to be.

What a data app is, in plain terms.

A data app is a small web application that lives in Fabric. It connects to a published semantic model and queries it in DAX, the same way a Power BI report does. Row-level security still applies. Users sign in with the same account they already use. So far, so familiar.

The difference is everything above the query. There is no canvas and no formatting pane. Each visual is built from code: a file with the DAX query, a file with the chart specification, and a file that ties them together and points at your model. Styling comes from a stylesheet rather than a theme file. Pages, navigation, cross-filtering and anything else you want all have to be written, not dragged into place.

Most BI people do not write web applications, so the realistic path is to build these with a coding agent. That is the point worth sitting with. The capability is impressive. The dependency it creates is the part nobody puts in the demo.

What changes.

The ceiling comes off. A Power BI report is restricted to what the tool and its rendering engine allow. A data app is restricted only by what you can express in code, which in practice means almost nothing is off limits. The fidelity you can reach is higher, and with an agent you can reach it faster than you could ever hack the same result into a report.

There is also a cleaner separation between your model and your reporting layer, which matters more than it sounds. We will come back to that in a later post.

What does not change, and what gets harder.

Here is the honest part. The moment you take full control of the canvas, you take on everything the platform used to handle for you. Performance is yours to manage. Accessibility is yours to get right. Consistency between visuals, pages and apps is yours to enforce, and that is hard when the code is generated by an agent that has no memory of how it styled the last one.

A Power BI report is Lego. A data app is a 3D printer. Most reporting needs Lego.

Maintenance is the one that bites later. If you built the app with an agent and never read the code, you cannot fix it without the agent. If your AI spend climbs or a tool changes, you are exposed. None of this is a reason to avoid data apps. It is a reason to go in with your eyes open.

Who this suits.

Data apps earn their place where the requirement is well beyond what a report can do, and where the team has the maturity to support a web application: enterprise and centralised BI, bespoke customer-facing experiences, situations where Power BI fidelity has become the bottleneck. For most mid-market reporting, which is self-service and needs to be simple, mature and robust, a Power BI report is still the right answer. It is simpler to build, simpler to govern, and your users already trust it.

It is also worth remembering that custom web dashboards are not new. Organisations built them long before Power BI existed. What changed is the cost. Agents make an old, expensive approach suddenly cheap enough to consider. That is the development worth tracking, not the novelty.

The dependency worth weighing.

One consideration deserves more weight than it usually gets. If your team builds a data app with an agent and never learns what is inside it, you have not removed the work, you have changed who holds the risk. The day something breaks, or a price needs to change, or a figure looks wrong, you will be unable to fix it without the agent that built it. That is a manageable position if you walk into it deliberately, with people who can read the code when they need to. It is a dangerous one if you back into it because the demo was quick. Treat the skill to maintain what you build as part of the cost, not an afterthought.

What we would do this quarter.

Do not migrate anything. Pick one internal use case, something low risk where a bespoke result would be useful, and trial a data app against it. You will learn more from one honest attempt than from a hundred demos, and you will find out quickly whether your team is ready to own what it produces.

If any of this sounds familiar, talk to us about your data.

What Fabric data apps change, and what they don't