Earlier this week we walked a small healthcare startup through a proposal for a sales system, and the sharpest question of the call had nothing to do with sales. The person heading up their systems had already picked a different platform for the pipeline. What he wanted to know was how he would ever get one view across it, the operational systems his team runs on, and whatever they buy next. So he stopped us mid-sentence and asked: what is Fabric?
It is a fair question. The name gives away nothing.
What Microsoft Fabric is, in plain terms
Microsoft Fabric is a place to put all of your data so that reporting can happen in one spot.
Right now you probably have a CRM here, an accounting system there, and an operations system somewhere else. Each one holds a slice of the truth and none of them holds the whole thing. Fabric is the warehouse that sits underneath all of them. It copies data out of each system on a schedule, lands it in one store, and gives your reporting something clean and complete to read from.
If it helps to place it against a name you may already know, Fabric lives in the same category as Snowflake or Google BigQuery. It is the layer beneath the dashboards, not the dashboards themselves.
Power BI is the part people see: the reports, the charts, the numbers leadership looks at on a Monday. Fabric is the plumbing that feeds it.
Power BI is what people look at. Fabric is where the data lives so that Power BI has something trustworthy to look at.
Neither one requires you to be a Microsoft shop
This is the part that surprises people, so it is worth saying plainly. Neither Power BI nor Fabric cares much what your source systems are.
Power BI connects to HubSpot, Salesforce, QuickBooks, Shopify, SQL databases, and spreadsheets. Fabric does the same, on a schedule, at larger volumes, and with somewhere to keep the results. Running your sales process in HubSpot puts neither of them out of reach, and nothing here needs Dynamics 365 underneath it. That is why we run this as its own practice rather than as an attachment to our Dynamics work.
When Power BI on its own is enough
Plenty of businesses never need the warehouse. A rough guide to where the line falls:
| Your situation | What we would usually suggest |
|---|---|
| One system, fairly standard reports | Power BI connected straight to the source |
| Two or three systems, light joins between them | Power BI with scheduled refreshes and a small data model |
| Several systems, or history your source overwrites, or heavy volume | Fabric underneath, Power BI on top |
The third row is worth reading twice. Most operational systems only show you today: what the pipeline looks like right now, what inventory sits on the shelf right now. They quietly overwrite yesterday. If a question you care about starts with "how has this changed since March", you need somewhere to keep the history, and that is the warehouse.
What this looks like in practice
The startup on that call described a common goal. Their sales pipeline lives in the CRM, their volume data lives in the systems operations runs on, broken out by location, and their cost data lives in finance. Three systems, three owners.
What they want is for someone quoting a new customer to see the likely cost to serve before the number goes out, and for leadership to see volume by site next to what each site costs to run. Answering either question means reading all three in one query and comparing this month against last. That is a warehouse-shaped problem, whatever the CRM happens to be.
The connectors are the easy part
Getting the data out is rarely where these projects get hard. Agreeing what the data means is.
Your CRM has one definition of an active customer. Your finance system has another. Someone has to decide which one the dashboard uses, and that decision belongs to your team, not to whoever builds the report. Skip it and you get a very polished number that two departments both refuse to believe.
Write down the ten questions you want answered, in plain sentences, before anyone connects a system. Half of them usually turn out to need a definition nobody has settled yet, and that is much cheaper to find out now.
Where to start
If you are running HubSpot, or anything else outside the Microsoft stack, and you want one view across all of it, the first conversation is short. Bring us your list of systems and the handful of questions you cannot answer today without exporting to a spreadsheet. That is usually enough for us to say whether it is a Power BI job, a Fabric job, or something a tidy-up of your existing reports would fix for far less. We are glad to have that conversation whether or not a Microsoft product ends up in the answer.