Every enterprise data platform eventually reaches the same awkward handoff.
It can reconcile billions of transactions, refresh risk positions every few minutes, and explain exactly why last quarter missed plan. Ask what the business expects next quarter, though, and someone opens Excel.
That is not an argument against Excel. Excel remains one of the best individual modeling tools ever built. The trouble begins when one person’s model becomes a shared business process. Now the organization needs common dimensions, controlled versions, security, comments, approvals, and a durable place to write the result. A workbook can imitate all of that. It is not very good at becoming all of that.
Fabric Plan is Microsoft’s attempt to bring that process into Fabric. A Plan item reads actuals and measures from a Power BI semantic model, lets the business enter assumptions and build scenarios, and writes configured planning data to Fabric SQL. Intelligence sheets then put the plan and actuals side by side for review.
Despite the name, this has nothing to do with Fabric capacity planning or Microsoft Planner. It also goes well beyond adding writeback to Power BI. Microsoft is positioning Plan as an enterprise and corporate performance management workload: budgets, forecasts, scenarios, operational plans, approvals, writeback, and variance reporting inside Fabric IQ.
The interesting questions are where that architecture fits, where it does not, and whether the current implementation is ready for the controls financial-services organizations require.
The Future Still Lives in Excel
Fabric already has a strong command of the past. Transaction history, snapshots, curated facts, and semantic measures are all designed to tell us what happened. With Real-Time Intelligence and shorter refresh cycles, Fabric is increasingly good at telling us what is happening now.
The future usually lives somewhere else.
Finance exports actuals into a workbook. Business units add assumptions. Files move through email and Teams. Someone builds a consolidation workbook that references the other workbooks. Version names become a form of oral tradition. By the time the forecast is approved, the actuals have moved and the plan has already started to age.
Fabric Plan changes that architecture without pretending the forecast is another actual. The semantic model remains the read path for historical facts, dimensions, hierarchies, measures, and row-level security. Planning sheets hold the editable drivers, allocations, versions, and scenarios. Configured results are written to Fabric SQL, which automatically replicates its tables into OneLake.
This fits the Zero Unmanaged Copies principle I use elsewhere in Fabric. Plan creates new data—of course it does—but it creates that data deliberately in Fabric SQL, with an owned path back into OneLake. Keep the planning tables separate from actuals and model scenario and version explicitly. That is what preserves the distinction between history and intent without creating another unmanaged extract.
The Workbook Becomes a System
Take a bank forecast. The existing semantic model already has deposit balances, loan production, fee income, funding cost, operating expense, legal entities, products, regions, and the approved measures used in reporting. Plan does not need to rebuild that model. It starts from it.
Planning sheets do most of the work people expect from an EPM product. Finance can establish a target. Business lines can contribute forecasts at the product or regional grain they understand. Values can be distributed through hierarchies, compared across versions, locked, commented on, and written back.
A planning sheet is also more than a grid for manual entry. A row model can turn a chart of accounts or cost-center hierarchy into inputs, calculations, subtotals, and outcomes. A measure model can start from the DAX measures the bank already trusts. A cube can take a summary target and allocate it across product, region, legal entity, and time using revenue, balances, headcount, or another measure as the weight.
For the bank, a forecast can start from manual inputs, an existing measure, a rolling period, or a statistical model. Microsoft’s current forecasting engine includes MSTL trend decomposition, exponential smoothing, and ARIMA. The team can then use Optimize to reach a target, maximize an outcome, or minimize one while keeping selected drivers inside defined bounds.
PowerTable is for data the business owns but no transaction system produces. An approved prepayment assumption, regional hiring target, allocation method, scenario status, or named owner has to live somewhere. PowerTable puts that data in Fabric SQL and adds forms, history, approvals, comments, and automation. That can eliminate a surprising number of small Excel-and-email applications.
It is important to be precise here. A semantic model can seed a PowerTable application, but the editable table lives in Fabric SQL. PowerTable does not write changes back into the semantic model or the original source behind it.
The models also do not need to be forced into one artificial grain. A regional revenue forecast, employee-level compensation plan, product plan, and corporate P&L are different models, not one table with different formatting. Infobridge can transform and consolidate their outputs into a common writeback table.
Finally, Intelligence sheets are the review and reporting layer. They can embed a live planning sheet, which means a changed driver or scenario can update the associated variance report immediately. That is the point where the forecast stops being a file finance produces and becomes a model management can actually work with.
Annual Budgeting is the Obvious use—and the Least Interesting One
Yes, Fabric Plan can run an annual budget. If that is the only use anyone can imagine, though, the organization is adopting a new planning workload to reproduce the most static version of the old process.
Plan makes the most sense when a recurring decision starts with trusted actuals, adds assumptions and local knowledge, allocates or optimizes across several dimensions, passes through a real review cycle, and returns as a versioned plan. Microsoft’s designed scenarios include bottom-up contribution, top-down allocation, rolling forecasts, driver-based scenarios, multidimensional consolidation, headcount and operational planning, and plan-versus-actual review.
Those patterns translate naturally into financial services, although Microsoft does not ship a finished bank-planning or insurance-planning model. The industry logic still has to be designed.
| Planning pattern | Financial-services example | What Plan contributes |
|---|---|---|
| Financial and performance planning | A bank forecasts deposits, loan originations, fee income, funding cost, and expense by product, region, and legal entity | Shared drivers, top-down targets, bottom-up contribution, versions, and consolidated P&L views |
| Driver-based scenarios | A card issuer varies purchase volume, revolving balance, yield, payment rate, fraud loss, and chargeback expense | Named scenarios and immediate propagation from assumptions to financial outcomes |
| Workforce and capacity planning | A wealth manager plans advisor capacity, household growth, service tiers, support ratios, and fee revenue | Headcount and workload drivers connected to revenue and service targets |
| Connected operational planning | A P&C carrier combines premium plans, approved frequency and severity assumptions, catastrophe-model outputs, claims staffing, and expense plans | Separate models at appropriate grains, consolidated through Infobridge |
| Business-maintained planning data | A life insurer maintains approved lapse, expense, commission, and investment-yield assumptions by product and scenario | PowerTable applications, change history, permissions, comments, and approvals |
| Variance and management reporting | A payments processor compares forecast transaction and revenue volumes with actual authorization, clearing, and settlement activity | Live plan-versus-actual reporting, commentary, and management output |
This is where I would draw the line. Plan should coordinate specialist calculations, not impersonate them. A bank should leave validated credit, liquidity, and capital models where they belong. An insurer should not rebuild reserving or catastrophe logic in a no-code sheet. Bring their approved assumptions and outputs into the planning process; do not turn the planning process into the model.
Microsoft also documents PowerTable for project plans, Gantt views, time entry, status tracking, and approvals. Documented does not mean sensible at every scale. A controlled assumption register fits. A high-volume core-banking interface plainly does not.
Continuous Planning is the Real Prize
An annual forecast begins going stale while it is still being approved. The more useful pattern is a rolling loop.
New actuals arrive. Planners change the few drivers that matter. Product or regional owners contribute at the grain they know. The workflow records who approved what. After approval, the scenario can be written to Fabric SQL, and the reporting model can compare it with the next set of actuals. The next forecast begins with the variance instead of another export.
The Semantic Model is the Planning Vontract
This is the part teams will be tempted to rush.
Do not connect Plan to whichever departmental semantic model happens to be nearby.
Each Plan item connects to one semantic model, and Microsoft currently says that connection cannot be changed after the item is created. Dimensions used together need valid relationships. Measures, hierarchies, names, and permissions determine what the planning process can see and calculate. Plan uses embedded tokens and always enforces the semantic model’s RLS. One unusual detail matters: a user with no assigned RLS role sees the union of all defined roles, while data outside every role remains hidden. Renaming the connected model can break the Plan item.
The semantic model therefore has to be treated as a production data product: explicit grains, conformed dimensions, tested measures, clear ownership, and a change policy. Connecting Plan to the nearest convenient model will simply move spreadsheet fragility into a more expensive place.
Writeback is the other contract. Plan can write to multiple Fabric SQL destinations and supports long, wide, and change-oriented formats. The with-changes formats write only modified values and retain the previous and new values; standard long and wide writeback replace matching dimensional rows. Deleting a row from the planning sheet does not delete it from SQL. Writeback access is also separate from general report access, and the current product writes planning results only to Fabric SQL. The writeback FAQ is worth reading before anyone designs the destination table.
Model the audit fields before the first sheet is built: scenario, version, approval status, effective period, dimensional key, user, and writeback timestamp.
GA Does Not Remove Every Enterprise Boundary
Microsoft made the core Plan workload generally available on July 28, 2026, with billing beginning August 1. The surrounding status labels are less clean. The billing page still says preview, while Plan support in Git integration and deployment pipelines is explicitly preview. Read the GA announcement alongside the documentation for each subsystem.
Continuous planning also expands the number of people who touch the plan, and Plan roles affect cost as well as permissions. Viewer, stakeholder, and planner activity is billed through 30-day role-based sessions, so the participation model belongs in the capacity estimate. Microsoft documents the current behavior in the Plan roles and billing guidance.
More importantly, several current limits can decide an FSS architecture before the feature discussion even begins.
Plan items do not currently work in workspaces or tenants using Private Link. Microsoft Entra B2B identities are not supported. PowerTable does not apply user-specific database RLS through its shared database connection, and Infobridge’s From Sheets blending does not support RLS. Plan connections to Direct Lake or DirectQuery semantic models require fixed credentials and do not support SSO. Service-principal CI/CD cannot automatically create the Plan application database. Renaming a workspace or connected semantic model can break the item.
If Private Link is mandatory, Plan is not the production answer today. If external participants need B2B access, the same is true. If the security design depends on per-user database RLS flowing through PowerTable, it needs to be redesigned before the pilot starts.
The current size limits are also real: 25 sheets and 50 visuals per Plan item, 1.2 million cells per Infobridge query or writeback operation, and one million rows for bulk CSV or Excel input. Microsoft maintains the current list on the known-limitations page.
The first deployment should therefore be an internal, recurring, dimensional planning process over a stable semantic model, without dependencies on Private Link, cross-tenant participation, or per-user RLS through PowerTable.
Fabric Finally Has a Future Tense
Fabric could already tell the business what happened. Increasingly, it could tell the business what was happening now. The forecast still lived somewhere else.
Plan brings that forecast into the architecture. Actuals remain read-only in the semantic model. Business assumptions and scenarios become managed planning data in Fabric SQL. Once those planning tables are explicitly modeled, approved results can meet the next set of actuals in the reporting model.
Do not start by replacing every planning tool. Start with one recurring forecast whose actuals are already trusted, whose drivers the business understands, and whose owners currently spend too much time reconciling workbook versions. Define the grain, contribution roles, approval path, writeback contract, and variance cycle before building the first sheet.
Fabric already knows what happened. Plan records what the business said would happen next. The variance no longer has to disappear between workbooks.
That is what it means for a data platform to have a future tense.
