Replicating a Power BI report in a Fabric App: a practical guide to the parts that fight back
Microsoft Fabric Apps let you build a data-driven application on top of the same semantic model that feeds your Power BI reports. One of the first things people want to try is the obvious one: take a report they already have in Power BI and rebuild it as a Fabric App page. We did exactly that, reproducing a financial overview dashboard, and this guide is the honest account of what that takes.
The short version up front, because it is the most useful thing we can tell you: in a Fabric App you are hand-building, in code, every visual that Power BI gives you out of the box. A sparkline, a formatted number, a chart with its months in the right order, these are configuration clicks in Power BI and lines of code in a Fabric App. That difference is the whole story, and everything below is a worked example of it. If your goal is simply a report, Power BI is faster. A Fabric App earns its keep when you need to do something a report cannot, and the reporting layer is the price of admission to that.
This is the Fabric App. Below is the Power BI version
To a viewer they are the same page. The effort is entirely in how each got built
What you are actually signing up for
Before the setup checklist, it helps to be clear about the mental shift. Power BI is a report authoring tool: you bind fields to a visual and the tool handles rendering, sorting, formatting, number abbreviation, tooltips and responsive resizing for you. A Fabric App is a web application: you have a blank canvas and a component library, and anything the page shows, you build.
Concretely, our stack split the work like this:
- React handles everything structural: the page layout, the left-hand navigation, the KPI cards, the tables, the toggles and selectors.
- TypeScript handles the data loading and the finance calculations.
- Vega-Lite handles the charts, and only the charts, the trend lines, the bar chart, the donut. That division matters: Vega-Lite is excellent for plotting a series but is the wrong tool for laying out a card or a grid, and trying to make it do layout is a common early mistake. Charts in Vega-Lite, everything else in React and CSS.
The data comes from the semantic model, the same one behind the Power BI report, read through the Fabric data service. You do not get Power BI’s visual layer along with that data. You get the numbers, and the job is to present them.
Below is Fabric Apps charts
Below is the Power BI version
Setup and prerequisites
Fabric Apps are a preview capability, so the setup has real prerequisites that will stop you dead if any one is missing. In our experience these are the ones worth confirming before you write a line of code:
A Fabric workspace where you have contributor or admin rights. The Fabric Apps workload enabled at the tenant level, which is an admin action, not something you can self-serve. A semantic model hosted on Fabric or Power BI capacity, with Build and Read permissions granted to you on that model. And the tooling to create and deploy the app itself, in our case the Rayfin SDK and its command-line workflow.
None of these are difficult individually, but they cross permission and tenant-admin boundaries, so if you are not the tenant admin, line those approvals up first. Discovering mid-build that the workload was never enabled is a frustrating way to lose a day.
One practical note that shaped our whole workflow: the app running locally on your machine has the layout but no live data. The only surface that renders the true figures from the model is the deployed app. So your loop is edit, deploy, look, not edit, refresh, look. Deploys cost real minutes, which quietly changes how you work, you batch changes and check them together rather than tweaking one pixel at a time.
The rendering fights, and how we won them
This is the part you came for. Every item below is something Power BI does silently and a Fabric App makes you build. None of them is conceptually hard. All of them cost time, and a few cost more time than they had any right to.
Sparklines in the KPI cards
Power BI puts a little trend line inside a KPI card with a checkbox. In a Fabric App there is no such checkbox. A KPI-card sparkline is a chart you build yourself: take the monthly series, draw it as a thin line in a small fixed drawing area, and place it beside the big number.
The subtlety is that a sparkline is not a shrunk-down chart. It has no axes, no gridlines, no labels, no markers, just the bare line. We built ours as a simple polyline in a hand-sized drawing area sitting next to the value, and the discipline was resisting the urge to add the things a normal chart has. Our first attempts crept in an end-of-line marker and a shaded fill under the line, neither of which was in the Power BI reference, and we had to strip them back out. The lesson that generalises: check the reference for exactly what the element does and does not have before building it, because it is easy to spend an afternoon perfecting a detail that should not be there at all.
Getting the sizing right
This one is deceptively fiddly. A KPI card holds a label, a large value, a comparison line and the sparkline, and getting them to share the horizontal space cleanly is a CSS layout problem you own entirely. Our sparklines initially rendered cramped and mis-proportioned because the text block and the chart were fighting over the available width.
The fix was in how the flex layout distributed space: letting the text block take its natural width without stretching, and giving the sparkline a flexible share of what remained, then sizing the chart’s internal drawing area to match its actual rendered box rather than a guessed nominal size. If the drawing area’s dimensions and the on-screen box disagree, the line renders distorted. Matching them is what makes a sparkline look intentional rather than squeezed. This is ordinary web layout work, but it is work Power BI never asked you to do.
Above is the Fabric Apps KPI cards, below is the Power BI KPI cards
The sparkline sharing card width cleanly with the value and comparison line. All hand-tuned CSS.
Months in alphabetical order (the one that cost us the most)
This is the standout gotcha, and it is worth telling in full because you cannot look it up.
Our trend charts came out with the months along the x-axis in alphabetical order, April, August, December, January, rather than chronological. This is a classic charting problem with a classic fix: tell the chart to sort the axis by the month’s actual order. So we set the sort property. Nothing changed. We set it a different way. Still nothing.
The cause turned out to be that the Fabric visual component silently ignores Vega-Lite’s sort property. It does not throw an error, it does not warn, it simply does nothing with that instruction. Every hour we spent adjusting the sort was spent on a control the platform was quietly discarding.
The fix, once we understood the cause, was to stop trying to sort at all. Instead we encoded the x-axis on a numeric month index, one through twelve, so the chart orders points by a real number, and then generated the visible month labels separately from that index. Order by numeric encoding, never by the sort property. That single sentence is now a permanent note in our build guide, and if you take one concrete thing from this article, let it be that: on this platform, do not trust sort on a chart axis, encode order as a number.
Abbreviating and rounding numbers
Power BI shows 55.56M and $800K and 51.27% because its formatting engine abbreviates and rounds for you, per visual, from a dropdown. A Fabric App renders exactly the number you hand it. If you pass a raw revenue figure into a KPI card, you get every digit.
So number presentation becomes your code. You decide where to abbreviate to millions or thousands, how many decimal places each context carries, where the currency symbol and percent sign go, and how the axis ticks read ($5.0M, $10.0M rather than 5000000). The trap here is inconsistency: it is easy to abbreviate one card to two decimals and another to one, or to round a KPI differently from the axis it sits above, and the page then looks subtly untidy in a way that is hard to pin down. The cure is to centralise formatting, decide the rules once, in one place, and route every displayed number through them, rather than formatting each value where it happens to be rendered. That way “millions to two decimal places with a leading currency symbol” is defined once and applied everywhere.
Below is an Fabric Apps Revenue trend:
Below is the Power BI revenue trend.
Formatting the rest of the look
Beyond numbers, a pile of smaller visual details each needed a deliberate decision that Power BI would have defaulted for you. The prior-year line being dashed rather than solid to distinguish it from actuals. The trend y-axes starting at zero on the revenue and cost charts, but deliberately staying zoomed on the net-margin chart so a one-percent movement is visible. Removing the vertical gridlines while keeping the horizontals. The area fill, or absence of it, under each trend line. None of these is hard. Collectively they are the difference between a page that looks like a finance report and one that looks like a developer’s first draft, and every one is a line of configuration you write rather than a property you toggle.
Below is the Fabric Apps charts
Below is the Power BI version
The honest verdict: Power BI is quicker for a report
Here is the conclusion we reached, stated plainly because it is the most useful thing for anyone weighing this up.
Building a report is faster in Power BI. It is not close. Every visual we have described, the sparkline, the formatted numbers, the correctly ordered months, the dashed comparison line, is something Power BI delivers with a few clicks and a Fabric App makes you construct by hand. If the deliverable is a report that people read, rebuilding it as a Fabric App is spending a lot of engineering effort to arrive back where Power BI already was.
That is not a criticism of Fabric Apps. It is a statement about what they are for. A Fabric App is a web application that happens to sit on your semantic model, and its value is that it can do the things a report fundamentally cannot: guide a user through a specific decision path, or, most powerfully, let a user write data back and have it recalculate and persist. The reporting layer is not the point of a Fabric App. It is the familiar surface you rebuild so that the unfamiliar, genuinely differentiating capability has somewhere to live.
So the decision rule we would offer is simple. If you need a report, build it in Power BI. If you need an application that includes reporting as one part of something larger, a Fabric App is the right tool, and this guide is your map to the reporting-replication tax you will pay to get there. Go in knowing that the tax is real, that most of it is paid in small rendering details rather than big architectural problems, and that at least one of those details, the silently ignored sort, will cost you an afternoon unless someone warns you first. Consider yourself warned.
To learn more about Microsoft Fabric and how we can help with Fabric Apps, see our Microsoft Fabric page.
