Answers/Microsoft Fabric

Do we actually need Microsoft Fabric?

Rob Collie·Founder and CEO, P3 Adaptive·September 2026

Somebody has told you that you need Microsoft Fabric. Maybe your Microsoft rep, maybe a partner, maybe the new data engineer who spent a weekend with it. You are trying to work out whether that is true or just the thing everybody is selling this year.

I spent thirteen years at Microsoft and was a founding engineer on Power BI, and P3 does a lot of Fabric work. So I have two reasons to say yes. I am going to say yes anyway, with a condition attached that I think matters more than the yes.

Why the answer is usually yes

Power BI is very good at modeling data and showing it to people. Fetching that data from a dozen systems, storing it and keeping its history is a different job.

Early on you don’t notice. You point a report at a spreadsheet or a database, it refreshes, everybody is happy. Then the sources multiply. Somebody wants the CRM next to the ERP, payroll next to both, and the budget that lives in Excel. A couple of those are SaaS tools that only talk through an API.

Power BI can call an API directly, and it is fragile when it does. There is nowhere to keep what came back, so every refresh asks for everything again. Incremental refresh is hard to get right. And when a call fails, the report quietly loads yesterday’s numbers and nobody finds out until a meeting goes sideways.

So you need a place to land the data and shape it before a model reads it. In a company that already lives in Power BI and Microsoft 365, Fabric is the obvious place to put that. It sits in the same tenant, uses the same sign-in, and your semantic models can read straight from its tables.

The problem is the order

Where Fabric goes wrong is sequence. The usual program starts at the bottom and works up.

Every month of that is spend with nothing a business person can look at. Worse, the pipelines got designed around the inventory, which is a list of what exists. What people need is a different list, and at that point nobody has seen it yet.

There is a second version of this I hear about a lot. A partner arrives with a “standard implementation,” holds a handful of meetings and stands up something the client had very little say in. It runs. Then the partner leaves, and the company owns a black box nobody inside the building understands.

Build the faucets first

We run it the other way round, and we call it faucets first. Before anybody designs a pipe, open a faucet and see what comes out.

In practice that means building the front end first, on stilts. The reports and the semantic model come first, sitting on whatever is easiest to get today: CSV exports, the Excel file finance already maintains, a one-time pull from an API. Nothing is automated yet. It doesn’t need to be.

Within a couple of weeks you have working reports on your real numbers, in front of the people who asked for them. They click around. They find the number that is wrong. They ask for the view they never would have mentioned in an interview, because now they can see what is possible.

The stilts are temporary on purpose. Somebody exporting a file by hand every Monday is fine for a month and miserable for a year.

The prototype is the map

That fortnight tells you things no assessment can:

• Which sources are load-bearing. Measured by what people kept reaching for. The list is always shorter than the inventory.
• How fresh each one has to be. Some views need yesterday. Some are fine once a month. That decides how much pipeline a source deserves.
• Where the definitions fight. Two versions of revenue, three of headcount. You find these the first time somebody puts two numbers side by side.
• What grain the model needs. Daily or monthly, by store or by region. Getting this wrong inside a pipeline is expensive to undo.

That is the spec for your back end, written by the people who will use it.

The prototype is the map. Build the pipes it tells you to build, in the order it tells you to build them.

Then automate the last mile

Once the reports have earned it, you take them off the stilts. The front end barely changes. What changes is where the data comes from.

In Fabric that usually means pipelines feeding a lakehouse in layers. You will hear them called bronze, silver and gold:

• Bronze is the raw copy, landed as it arrived. When something looks off later, you can always go back to what the source actually sent.
• Silver is cleaned and conformed. Types fixed, duplicates gone, customer IDs that finally match across systems.
• Goldis shaped for the model, the fact and dimension tables your reports read. The business logic lives here once, where today it is probably copied into every report’s Power Query.

API sources are where this pays off fastest. A pipeline can fetch only what changed, keep history, retry a failed call and tell somebody when it gives up. Try doing that from inside a Power BI refresh and you will see why people stop trying.

And you don’t build it all at once. Automate the sources the prototype proved matter, starting with the one that hurts most to do by hand. Add the next when it earns it. Fabric grows with the business, so you can start small and size up when the workload actually shows up.

Who can change it after we leave

We deploy an orchestration framework we have already built into your own tenant. It runs the loads from configuration, logs every run and restarts cleanly after a failure. Adding a table to a source it already knows is closer to adding a row than writing a pipeline. There is more on it on the Fabric page.

You own it outright. Your team can read it, run it and extend it once we are gone, and we build it with them so they can.

When you are comparing Fabric partners, ask each one who will be able to change the pipelines after the engagement ends. The black-box build is the one I would worry about most, because it looks finished on the day the partner leaves.

When you don’t need it yet

“Probably” is the honest word in the answer at the top. Some companies can go a long while without Fabric.

• One well-kept database and a handful of reports. If Power BI refreshes happily off your SQL Server, a lakehouse gives you one more thing to run.
• Almost everything comes from one system that already has decent reporting tables. Model on those and revisit when a second source arrives.
• Nobody uses the reports you already have. Plumbing will not fix that. Find out why first.

Fabric also has a running cost. Capacity costs money for every hour it runs, whether or not anybody opens a report, so the platform should be carrying real work before you size it up.

Four things you can check this week

Where I’d start

Pick the two or three reports people are loudest about, usually the ones somebody rebuilds by hand every month. Build them on exports with a real semantic model underneath, and put them in front of the people who asked. Two weeks is enough.

Then look at what they used. That tells you which sources to automate first and how fresh each one has to be. It also shows you which definitions need settling before they go into a gold layer. Build that in Fabric, one source at a time. If you are still weighing Fabric against the alternatives, I wrote about how to choose between Fabric, Snowflake and Databricks.

You will still end up with a lakehouse. It will be the one your reports needed.