The Driver Model in Microsoft Fabric IQ - Planning That Actually Reflects the Business

Most planning models are spreadsheets full of numbers that nobody can explain. Revenue goes up 8 percent next quarter because someone typed 8 percent. Ask why, and the answer is a shrug or "that's what we did last year plus a bit". This is the quiet disease of corporate planning, and it is exactly what a driver model is meant to cure. Microsoft Fabric IQ's planning capability puts the driver model at the centre, and if you have spent years watching finance teams argue over numbers with no shared logic underneath, that is a genuinely welcome shift.

I want to walk through what the driver model in Fabric IQ actually is, why it matters for Australian businesses trying to plan with some rigour, and where I have seen these things go sideways. Driver-based planning is not new as a concept, but having it as a first-class part of the platform where your data already lives changes what is realistic to build.

What a driver model is, without the jargon

A driver model connects the outputs you care about, revenue, cost, headcount, margin, to the operational things that actually move them. Instead of typing a revenue number, you say revenue is a function of units sold times average price. Units sold is a function of sales reps times deals per rep times win rate. Now your plan is not a number, it is a chain of logic, and every figure at the top traces down to assumptions you can see, question, and change.

The drivers are those underlying levers: the number of reps, the win rate, the price, the churn rate, the production yield. Change a driver and the model recalculates the outputs that depend on it. That is the whole idea. The Fabric IQ documentation on the driver model lays out the formal concepts. What I want to add is why this structure beats the spreadsheet you are probably using now, and what it takes to build one that people trust.

The value is not really the maths. It is that the model forces the business to make its assumptions explicit. When revenue is units times price, someone has to own the unit forecast and someone has to own pricing, and now those are real conversations instead of a single blended number that hides who assumed what. Half the benefit of a driver model shows up before you have run a single scenario, just from writing down how the business actually thinks it works.

Why this belongs in Fabric and not a spreadsheet

You can build a driver model in Excel. People have, for decades. The reason to do it in Fabric IQ is that the drivers can connect to your actual data rather than living as static, hand-typed assumptions that go stale the moment they are entered.

Your win rate is not a guess if it comes from your CRM. Your production yield is not a made-up number if it flows from your operational systems. In Fabric, the data is already there, in OneLake, alongside the planning model, which means a driver can be grounded in what really happened instead of what someone remembered. That closes the gap between "the plan" and "the numbers", which in most organisations are two separate universes maintained by two separate teams who quietly distrust each other.

This is the part I think matters most and gets undersold. A driver model that sits on top of live data becomes a living thing. Actuals come in, and you can immediately see how reality is tracking against the drivers you assumed, not just against a target. Your win rate assumption was 25 percent and the CRM says it is running at 19, so you know exactly which lever is going to blow the forecast and you know it now, not at quarter end. That early-warning quality is the real prize, and it is only possible because the plan and the data share a home. Getting a business's data into that shape is a lot of what our Microsoft Fabric consultants spend their time on, because a driver model is only as good as the data feeding its drivers.

Getting the driver structure right is the hard part

Here is the honest bit. The technology is the easy part. The hard part is deciding what the drivers actually are, and this is where I see most driver-model projects struggle.

There is a strong pull towards too much detail. Someone decides the model should capture every conceivable factor, and you end up with two hundred drivers, most of which nobody can forecast and half of which cancel each other out. The model becomes so complex that no one understands it, which is the exact problem you were trying to solve, just dressed up in fancier tooling. A driver model with two hundred inputs is a spreadsheet with extra steps.

The opposite failure is a model so simple it does not reflect how the business really works, so people do not believe its outputs and quietly go back to their own spreadsheets. The skill is finding the handful of drivers that genuinely move the outcome and stopping there. For a manufacturer that might be production capacity, yield, and order volume. For a professional services firm it is headcount, utilisation, and rate. For a mortgage broker it is lead volume, conversion, and average loan size. Three to seven real drivers per output usually beats fifty, every time.

My rule is that a driver only earns its place if someone in the business can both forecast it and act on it. If nobody owns a driver and nobody can change it, it is not a driver, it is noise. This is a business-modelling conversation as much as a technical one, and it is exactly the kind of thing we work through with clients as part of our AI strategy consulting, because the shape of the model has to match the shape of how the business actually makes decisions.

Scenarios are where it pays off

Once you have a driver model, scenario planning stops being a painful annual exercise and becomes something you can do in an afternoon. Because the outputs are derived from drivers, you change a driver and see the whole plan move. What happens to margin if we lose two reps. What happens to cash if collection days slip by a week. What happens if input costs rise 12 percent and we only pass half of it on.

In a spreadsheet, each of those is a fragile copy-paste exercise that someone breaks by forgetting to update a cell. In a proper driver model, they are a change to one number and a recalculation you can trust, because the logic is consistent everywhere the driver flows. This is the capability finance teams say they want and rarely have, because their spreadsheets are too brittle to support it safely.

The thing to be careful of is treating scenarios as prediction. A driver model is a reasoning tool, not a crystal ball. Its job is to tell you what follows if your assumptions hold, so you can decide whether the assumptions are reasonable and what to do if they are not. The organisations that get value from this use it to have better arguments, not to end them. A model that says margin drops to 4 percent under a plausible downturn is not predicting doom, it is telling you to have a plan for that lever before the downturn arrives.

Where Fabric IQ planning is still rough

I try to be honest about maturity, so here is the caveat. Fabric IQ's planning capability is newer than the modelling ideas underneath it, and the concept of a driver model is far more established than any one platform's implementation of it. If you come in expecting the depth of a mature, dedicated planning suite that has been refined over a decade, you will find gaps.

What Fabric IQ has going for it is the integration. The driver model living next to your data in OneLake, inside the same platform as your analytics and increasingly your AI, is a real structural advantage that standalone planning tools cannot match. So the trade is capability breadth today versus integration and trajectory. For an organisation already committed to Fabric, building the planning model where the data already lives makes a lot of sense, and the platform is improving quickly. For one with a deeply embedded specialist planning tool that works, I would not rush to rip it out. Weigh it honestly rather than chasing the newest thing.

What to watch out for

A few closing warnings from the field.

Ownership is everything. A driver model with no owners for its drivers rots fast, because nobody updates the assumptions and it drifts from reality. Assign every driver an owner in the business before you build, not after.

Do not let the model outrun the organisation's ability to feed it. A beautifully detailed driver model that needs data the business does not reliably collect is going to run on stale or guessed inputs, which is worse than a simpler model on solid data. Build to the data you actually have.

And keep it explainable. The entire point of a driver model is that people can trace and question the logic. The moment it becomes a black box that only one analyst understands, you have recreated the problem in more expensive software. If a senior manager cannot follow the chain from a top-line number to its drivers in a couple of minutes, the model is too complex.

The bottom line

The driver model in Fabric IQ is worth taking seriously because it forces the business to say out loud how it thinks it works, and then grounds those assumptions in real data instead of hopeful typing. The maths is straightforward. The value is in choosing a small set of drivers that genuinely move the outcome, giving each one an owner, and using the model to reason about scenarios rather than to pretend at prophecy. Done well, it closes the gap between the plan and the numbers, which in most organisations has been open for years.

If you are looking at Fabric for planning and analytics and want help building models the business will actually trust, that is the sort of work we do. Have a look at our Microsoft Fabric consulting, or get in touch and we will talk through what your drivers really are.

Reference: Driver model