Plan

The forecast almost always begins the same way. Someone exports the numbers to a spreadsheet.

It feels harmless. You just need a place to type next year's targets, try a few what-if numbers, and write both a hopeful plan and a careful one. So you pull the current numbers into a workbook, and you plan.

But look at what that one click did. The moment the data left, it stopped being the data. It became a copy. It was correct at the moment you took it, and a little more wrong every day after. A late order lands, a refund posts, a region gets restated, and none of it reaches your workbook. The plan and the truth slowly drift apart, and nobody sees the gap until the review, when the forecast and the actuals no longer even agree on where you started.

That drift is not a discipline problem. It is built into the export itself. A snapshot cannot track a moving thing.

The export is the moment it breaks

Look again at where things went wrong. It was not the typing of targets, and not the what-ifs. It was the export. The moment a snapshot leaves the source, you have two objects where there was one, and after that they can disagree.

The frozen line is not the result of carelessness. It is doing exactly what a snapshot does: holding still. The truth is doing what truth does: moving. The gap between them is not a mistake anyone made. It is the cost you always pay for planning on a copy instead of on the real thing.

So the fix is not "refresh the spreadsheet more often." That just means chasing the moving line by hand, and you will always be a few days behind. The fix is to never lift the plan off the foundation at all.

Plan on the shared foundation, not a fork of it

Here is the change. Your reports read from the governed model. Your metrics read from it. Your AI agent reasons over it. The plan should sit in that same place, reading the same numbers as everyone else.

When the plan lives on the shared foundation, the questions that used to be hard become easy. Plan versus actuals is not a matching job across two workbooks. It is one read against one dataset, because the plan and the actuals were never separated in the first place. Change a target and the comparison recomputes. Restate a region and both sides see it at once. There is no sync step, because there is nothing to sync.

This is the same idea that sits under every concept before it. A property is a value plus its meaning, so nobody has to guess. A knowledge graph is built from live data, so it never goes stale. A plan on the shared model is a forecast that cannot drift, for the same reason: it is not a copy of the truth, it is the truth, with targets drawn on top.

Drag the target below to set the plan. Then push a change into the real data and watch the live plan take it in while the exported snapshot drifts.

Watch what happens when reality moves. Post a late order or restate a region, and the live plan takes it in at once, while the exported snapshot keeps comparing against the numbers it froze. Drag the target and both recompute together, because that part is just a formula. The real difference is the source: the live plan reads reality, the export cannot. That is the whole promise: the plan tracks reality on its own, because it never left reality to begin with.

Plan, on the same foundation as everything else

In Microsoft Fabric, this is the Plan capability: no-code, collaborative planning, budgeting, and forecasting built on the same governed foundation as the rest of the platform. It sits on OneLake, next to the ontology, the knowledge graph, the semantic model, and the data agent (Fabric's name for an AI agent grounded in your data), and it reads the same trusted data they do.

Because it is on that shared foundation, it does the things a spreadsheet cannot. You set targets and build scenarios without writing code. You write agreed values back, so the plan is not a read-only copy but something the business commits to, right in place. And you compare plan against actuals directly, over the same OneLake data both live on, with no export and no matching step between two separate files.

The write-back is what makes it a loop and not a dead end. A number you set in the plan does not stay stuck in one item. It lands back on the shared foundation, where a report can chart it, a metric can track it, and a data agent can answer questions about it at the same time as it answers questions about the actuals. Plan and reality live in one place, so an agent can reason across both without you joining anything together by hand.

One honest note, the same one that runs through this whole track. Fabric IQ is in preview as of July 2026. The exact screens and buttons may still change. The lasting point, the one worth keeping, is the shape: planning belongs on the governed foundation, not in an export beside it.

The one trap

The trap is treating "export to plan" as a harmless convenience, a safe first step. It is not neutral. It is the exact moment the plan stops being connected to the truth. Everything painful that follows, the matching work, the version called final-v7, the review where the numbers do not match, all of it traces back to that one click. If your planning starts by lifting a copy off the foundation, no amount of care later can fix it. Keep the plan on the shared model, and this whole group of problems never begins.

That is planning: one more thing built on the same governed truth, kept close so it cannot drift. Next we look wider, at the rest of that world: the integrations that let this foundation reach the tools your business already runs on.