Fabric Planning, answered

There is nothing to buy separately, no separate vendor contract, and no additional licensing. Fabric Planning ships as a workload inside Fabric IQ called “Fabric Plan.” Our understanding is that it is a first-party item. It runs on your existing Fabric capacity, governed by the same security model and admin controls as every other Fabric workload.

As we understand it, the technology was built by Lumel and licensed by Microsoft for exclusive native use within Fabric. Think of it like Microsoft Copilot: powered by OpenAI, but nobody calls it a third-party product. Fabric Planning works the same way: from the customer side, you buy it from Microsoft and use it inside Microsoft Fabric.

Fabric Planning is native. One platform, one security model, one vendor.

For context on where the planning market stood before this shift, see the FP&A Market Guide co-authored by Khaled Chowdhury and Paul Barnhurst.

Every third-party Power BI planning solution in the Microsoft ecosystem followed the same pattern: a custom visual built on the Power BI SDK, connected to a separate modeling engine, writing data back to Fabric SQL or another database. None of these custom visuals were certified by Microsoft, which created a real challenge from a security and CISO perspective, because an uncertified visual could technically send data anywhere.

Fabric Planning is architecturally different. It is not a custom visual built on the Power BI SDK. It is a native Fabric workload, a Fabric artifact inside Fabric IQ. The planning application and the data reside in the same platform, under Fabric’s own security model. There is no external modeling engine, no uncertified component, and no separate license for the front end versus the back end.

This is not a repackaging of the old approach. The Power BI SDK is a well-known bottleneck that has not seen significant improvement in a long time. Even though Lumel’s planning expertise and concepts carry forward, the Fabric Planning workload was built from the ground up without the limitations of the Power BI SDK.

When previous solutions claimed they were “part of Fabric,” what they meant was that they wrote back to Fabric SQL. Fabric Planning is built inside Fabric, governed by Fabric, and secured by Fabric. The app and the data live in one place.

This is a fair concern. Microsoft deprecated PerformancePoint Services, and firms that built FP&A practices around it were left to find alternatives. That history is real and people remember it.

The structural difference is that PerformancePoint was a standalone product, maintained separately from the core data platform. When Microsoft shifted priorities, it was easy to cut. Fabric Planning is embedded directly into Fabric IQ as a native workload. Microsoft Fabric is not a side bet; it is one of Microsoft’s most strategic platform investments. Ripping a native workload out of your flagship data platform is a fundamentally different proposition than sunsetting a standalone product.

It is also worth noting how this was launched. The launch announcement did not frame this as an ISV offering or a partner solution. It was announced as Fabric Planning, a Fabric workload, with a small “powered by Lumel” note. That positioning tells you where this is headed. Expect the Lumel name to fade into the background the same way you do not think about the vendor behind any other Fabric workload.

One of the underappreciated advantages of this model is that Fabric Planning has a dedicated development team. In our experience, features built inside a large platform team compete for resources and shift with changing priorities; as we understand it, this team is focused entirely on planning. That focus means faster iteration and less risk of the feature stalling because a different initiative took priority internally.

Lumel is not an unproven vendor Microsoft took a chance on. Their team, a couple hundred employees strong, was seasoned through SAP. They had the planning technology, but the platform was not ready for it. Power BI changed that by giving them the adoption path, putting their tools in front of hundreds of enterprise customers through custom visuals that became market leaders. They won the Best Overall EPM Vendor in 2025 (BPM Partners study) and the Financial Modelling Innovation Award in 2020. Fabric completed the picture by giving them a platform where the technology could be fully native, not constrained by the Power BI SDK. In our view, that track record is why Lumel’s technology became the native planning and writeback solution: a team and a product that had already won the market through Power BI and were ready to deliver at the platform level through Fabric.

There is also the adoption flywheel to consider. The path from Excel to Power BI to Fabric to Fabric Planning is a natural progression. There are over 20 million semantic models already built in Power BI. People are not starting from scratch. They are extending what they already have. That kind of installed base creates gravity that PerformancePoint never had.

Does that guarantee permanence? Nothing in technology is guaranteed. But the strategic importance of Fabric, the dedicated development team, the adoption flywheel, and how Microsoft chose to position this all point in a very different direction than PerformancePoint.

Not necessarily, and not just because something new exists. Fabric Planning has been generally available since July 28, 2026, so this is now a proper evaluation rather than a wait-and-see.

If your current solution is working, it is working. Any time you change platforms, there is a real cost of change: migration effort, retraining, rebuilding models, and the inevitable disruption to a planning cycle that your business depends on. That cost needs to be weighed against what you gain.

That said, there are specific components within Fabric Planning worth exploring today even if you are not ready for a full switch. Data management through PowerTables and financial reporting through Intelligence Sheets are capabilities that can add value alongside what you already have, without requiring you to rip and replace anything.

The decision is a proper evaluation: feature comparison, native integration benefits, security posture, total cost of ownership, and whether the consumption-based pricing model works better for your organization than your current licensing structure. Every coin has two sides, and no single solution is always better across every dimension.

The right move today is to try it, understand what it can do, and make a deliberate decision when the time is right.

In the near term, no. The Power BI SDK is still there, and the third-party planning solutions built on it are not being deprecated by Microsoft. Many of them are genuinely good products. We reviewed the landscape in the FP&A Market Guide, and several of those solutions deliver real value.

That said, it is worth reading the writing on the wall. Power BI is not where Microsoft is putting its investment energy. Fabric is. The Power BI SDK has not seen significant improvement in a long time, and there is no indication that is changing. The solutions built on it will continue to work for the foreseeable future, but the platform underneath them is not evolving.

Will they be deprecated? I do not see that happening in the foreseeable future. Will they be significantly improved beyond where they are today? I do not see that happening in the foreseeable future either. The ceiling for what those solutions can do is largely set by the SDK they are built on, and that SDK is not moving.

Other vendors may build planning workloads on Fabric using the workload development kit, and some likely will. But those would be third-party Fabric workloads, not Microsoft offerings. We do not expect Microsoft to ship Fabric Planning version A and version B. There is one native planning workload, and that is Fabric Plan.

For organizations evaluating their long-term planning architecture, the trajectory matters as much as the current state. The current state is fine. The trajectory favors Fabric.

Fabric Planning ships as a single Fabric Plan item that includes three integrated capabilities, all built on one Fabric foundation, sharing the same data, the same security, and the same backend. Each capability is organized around a different type of “sheet.” Sound familiar? Some things never change.

Planning is the core budgeting and forecasting engine. Build and manage enterprise plans directly on your semantic models. Collaborate across teams with cell-level commenting, multi-role workflows, and governed approvals. Plans write back to Fabric SQL automatically. Includes integrated budgeting and forecasting, scenario modeling and what-if analysis, and multi-role collaboration and approvals.

Intelligence is the variance reporting and analysis layer. Think of it as a visual and reporting layer for planning, built on Lumel’s 10+ years of developing financial visualizations. See plan versus actuals in a single, reconciled view. Variance measures are calculated automatically. Dashboards, storyboards, and ad-hoc analysis surface what matters without waiting for a separate BI cycle. Includes IBCS-certified financial reporting and ad-hoc analysis for business users.

Data Management handles forward-looking reference data. Your systems of record manage what exists today. Data Management manages what is coming: projected customers, planned products, future cost centers. Build no-code apps for any structured workflow, with row and column-level access control, approval routing, and 1:1 sync to Fabric SQL.

All three can be used together as a full planning suite or independently based on what you need. You do not have to adopt everything at once.

Both, and yes, we know. Microsoft naming strikes again.

Fabric Planning is the name of the capability. It is the marketing term for the overall planning experience inside Microsoft Fabric. When people say "Fabric Planning," they are talking about the ability to do budgeting, forecasting, and scenario modeling natively in Fabric. This is what I call it.

Fabric Plan is the name of the actual Fabric item, the technical artifact you create inside a workspace. When you click "New" in a Fabric workspace and see "Plan" in the list, that is the Fabric Plan item. It is the container that holds your Planning sheets, Intelligence sheets, and Data Management (PowerTable) sheets.

In Microsoft documentation, you will see "Plan" when referring to the artifact and "planning in Fabric" or "Planning in Fabric IQ" when referring to the capability.

Nothing is free, but there is no separate pricing. Fabric Planning follows the same all-inclusive pricing model as every other Fabric workload. There is no separate license, no additional SKU, and no per-user fee.

Like any Fabric workload, Fabric Planning consumes capacity units (CUs). Each person who opens or works in a plan holds a 30-day session on that capacity at one of three rates: Viewer 0.05 CU, Stakeholder 0.23 CU, Planner 1.16 CU. What they do sets the role: opening any item to look is Viewer; only creating a Planning sheet or editing its design is Planner; almost everything else, from entering and changing plan numbers to building PowerTables and Intelligence sheets, is Stakeholder. Background automation jobs (PowerTable automation, connected planning in Infobridge) bill 2 CU-hours per successful job on the same capacity. Microsoft Learn’s billing page suggests an estimated 30% capacity buffer for the other Fabric workloads that share it. You can try it on an F2; production deployments realistically start at F4. The cost structure follows the same reservation versus pay-as-you-go model you are already familiar with from Fabric.

This is where Fabric Planning fundamentally breaks from traditional EPM tools. With those platforms, if you have 200 budget contributors who only enter data for three months out of the year, you are still paying for all 200 licenses for all 12 months. With Fabric, you only consume capacity when those users are actively working. You can scale up your Fabric capacity during budget season and scale it back down when that cycle ends, as long as the smaller size still covers your active sessions. You pay for what you use, when you use it. Read the danger zone before you pause, delete, or move a capacity.

To size your own deployment by role, use the capacity and cost calculator.

A session starts the first time someone opens or works in a plan item, in reading view or edit mode, and lasts 30 days (730 hours). It can't be ended early. You never pick a role: everyone typically starts as a Viewer, and actions upgrade you automatically. Opening any item to look, whether a Planning sheet, a PowerTable or an Intelligence sheet, keeps you a Viewer. Only creating a Planning sheet or editing its design (structure, rules, write-back destinations) makes you a Planner. Almost everything else makes you a Stakeholder: entering or changing plan numbers, approving, writing back, and creating or editing PowerTables and Intelligence sheets. (Microsoft's roles page adds one exception: creating a new plan item upgrades the creator to Planner; see the PowerTable-only question below.) A user holding several roles on one capacity is billed once, at the highest. An upgrade closes the lower session, prorated, and opens a new 30-day session at the higher rate.

For what each role can do and who should hold it, see the roles page.

No, not since August 19, 2026. Microsoft's roles page states it in an Important note: "Planning assigns the Planner persona only when you create or edit planning sheets." Building PowerTable data apps and Intelligence reports is Stakeholder work, at 0.23 CU instead of 1.16 CU.

A Viewer session: 0.05 CU held for 30 days, under $7 at US list rates. Microsoft's billing documentation says opening a plan item in reading view starts a session, so the peek is billable. The upgrade is what to govern: entering one number makes that person a Stakeholder (about $30), and creating a Planning sheet or editing its design makes them a Planner (about $152). Building a PowerTable or Intelligence sheet stays at Stakeholder.

No cap. Within the 30-day session the charge is fixed however much you do: a hundred scenarios, thousands of edits, as many PowerTable data apps and Intelligence reports as you like. What scales with usage is the compute underneath, drawn from the Fabric capacity you already own. The one line you can't cross without an upgrade is creating a Planning sheet or editing its design, which makes you a Planner.

You're billed for the window, not the volume. Once you engage, that 30-day window is committed at your role's rate, and ten entries cost the same as ten thousand. The same fixed charge that removes the ceiling also puts in a floor. The useful question isn't the bill, it's whether that person belongs in the plan at all: if they do, the session cost is a rounding error next to what their time costs; if they don't, that's a governance question, not a billing one.

No. Microsoft states a session can't end early and a role can't be downgraded inside one, so the window runs out at the rate it opened at. Cost control happens before the click, by governing who creates Planning sheets.

No. Billing is based entirely on sustained CU, and sustained CU only starts when there's activity. The first time someone acts, that sets their role and starts a 30-day billing window for it. If nobody opens a plan item, no role is triggered and there is no charge. No activity, no cost.

The one nuance is automation: a background automation job that fires in an otherwise idle month still bills its small per-job draw (see the Automation Jobs section). No sessions and no jobs means no charge.

Microsoft's roles page says items with only PowerTable sheets, or only Intelligence sheets, offer just the Stakeholder and Viewer roles, and its August 19 announcement says editors of such items bill at Stakeholder. The same roles page also says creating a new plan item upgrades the creator to Planner. Until Microsoft reconciles the two, budget one Planner session for whoever sets the item up, then Stakeholder and Viewer for everyone else. The first Planning sheet anyone creates opens a Planner session as usual.

Only if an admin turns it on. Microsoft's roles page documents a workspace setting, Prompt on Session Upgrade, which is off by default. The same page says creating a new plan item upgrades the creator to Planner with no prompt. Lumel's documentation also describes tenant settings that control who can upgrade to Planner or Stakeholder sessions.

A sustained CU is a reserved seat. The first time a user acts in a role, they open a 30-day session for that role, and that session occupies a fixed share of your F-SKU for the 30-day period, whether they log in every day or once. It is not a running meter: no CU per hour, no accumulating CU-seconds to add up. The number maps directly to the F-SKU scale. A concrete example: one Planner holds 1.16 CU, which is 58% of an F2's total 2 CU. That is why one Planner alone nearly fills the smallest SKU, and why F4 is the realistic floor for production planning.

The calculator adds up sustained CU across your users and recommends the F-SKU that fits.

Because they are billed differently. Automation jobs bill transactionally, per successful job (2 CU-hours each), the same way other Fabric capabilities such as notebooks, pipelines, and Power BI refreshes are metered. There are two job types, PowerTable automation and connected planning in Infobridge. Failed jobs aren't billed, and job billing is the same whatever the user's role. Sustained CU is different: it is a continuously held reserved seat for the full 30-day session, held by Viewer, Stakeholder, and Planner roles regardless of how often they act.

To size your F-SKU, the calculator still needs one number, so it converts total automation CU-hours over the 30-day period into a CU-equivalent: total CU-hours divided by the hours in the period, the same conversion that defines the sustained CU rates themselves. That equivalent is what shows up in the capacity tank and dollar breakdown alongside the roles, even though automation jobs are not held continuously the way a role's session is.

See the calculator's Automation Jobs section for what counts as a job and two concrete examples.

One Planner holds 1.16 of an F2's 2 CU, so F4 is the practical floor once real planning starts. Microsoft notes that small SKUs like F2 and F4 are the easiest to overcommit. A data-management-only deployment, with no Planning sheets, is mostly Stakeholders and Viewers; budget one Planner session for setup (see the PowerTable-only question). Put your numbers in the calculator.

They share the same pool, so size for the planning peak on top of your existing peak rather than as a separate allocation. The calculator's buffer setting is one way to build that headroom in deliberately.

Microsoft Learn's billing page suggests an estimated 30% capacity buffer for the other Fabric workloads on the capacity, which is the calculator's default. Planning sessions keep being recorded even when other workloads exhaust the capacity.

The same thing that happens on pay-as-you-go: both capacity types hard-cap at the CU limit, and both offer overage billing as a toggleable setting. With overage on, additional CU-seconds are charged at 3x the pay-as-you-go rate. With overage off, the capacity throttles. Reserved and PAYG behave identically here; the difference between them is price and commitment, and the way to avoid the question entirely is to size with headroom (see the calculator's buffer setting).

Yes. Microsoft's billing documentation tracks sessions per tenant, user and capacity, so one person active on two capacities has two sessions. Within one capacity it is the reverse: several workspaces roll up, and the user is billed once at the highest role they hold.

Traditional EPM tools charge an annual license for every seat, and a viewer seat often costs nearly as much as a builder seat, regardless of how much anyone uses the tool. Fabric Planning is consumption-based: you pay for active use only, and the Viewer and Stakeholder tiers are priced deliberately low to make broad participation cheap. Think of it as SaaS within SaaS: the planning workload draws from the same Fabric capacity you already run analytics on, and unused capacity stays available to the rest of Fabric. The comparison favors Fabric Planning most for seasonal cycles with many occasional participants, which is what most planning processes look like. Put your own numbers in the calculator to see where you land.

A fair question with an honest answer: we have not confirmed whether Copilot and AI features in Fabric Planning draw from the same CU pool or bill separately. Microsoft's billing documentation does not address it. Check Lumel's pricing page for the latest before committing, and treat AI usage as a line item to verify during a POC.

Fabric Planning is generally available, but the three components have not had the same time in market.

Data Management (PowerTables) was first announced at FabCon Europe last year and has had the most time to mature. Of the three components, this is the closest to production grade.

Intelligence is also well along. The financial reporting and visualization capabilities draw from Lumel’s 10+ years of building these tools, so the underlying technology is proven.

Planning is where I would exercise the most caution, not because the technology is lacking, but because planning exposes a harder question: how good is your data? The technology is not the bottleneck anymore. Your data foundation is. If your actuals, your chart of accounts, and your dimensional structures are not clean, no planning tool will save you.

My recommendation: start simple. Pick something like expense planning where the data is well understood and the model is straightforward. Build confidence and prove out the workflow before moving to more complex use cases like revenue forecasting or workforce planning. Layer complexity on top of a working foundation, not the other way around.

Two steps:

1. Your Fabric admin enables Fabric Planning in the tenant admin center. This can be turned on for the entire organization or for specific users.
2. Navigate to any workspace backed by Fabric capacity, and Fabric Planning is available.

For a simple walkthrough of how to turn it on, see this guide.

Yes. Fabric Planning works on a Fabric trial capacity. I have tested it myself.

Most likely, yes. Fabric Planning consumption is driven by the number of users actively working in it (plus any background automation jobs), not by the complexity of what they are building. Each person who opens a plan holds a 30-day session at their role's rate.

The real question is not "is my capacity big enough" but "how many people will be active in the same 30 days, and in which roles." A small team experimenting with expense planning on an existing capacity is a very different workload than 200 budget contributors entering data during the same two-week window.

If you have a Fabric trial available, start there. It worked for me on trial capacity. That gives you a risk-free way to understand the consumption profile before committing any production capacity to it.

Yes. Fabric Planning is a horizontal product. Whatever you can plan in Excel, you can plan in Fabric Planning. Headcount forecasting, cost forecasting, revenue planning, capital planning, scenario modeling, all of it.

The important thing to understand is that Fabric Planning gives you the canvas and the tools, not a pre-built solution for any specific use case. Think of it the way you think about Excel: it does not come with your budget already built. It gives you the capabilities to build whatever you need.

This means you get the flexibility to design your planning models the way your business actually works, but it also means you are starting from a blank canvas at this point. We are going to be rolling out accelerators soon to help with common use cases, but for now, you get to leverage the planning capabilities as you see fit.

The right move is to start simple. Pick a use case where your data is well understood, prove out the workflow, and build from there.

Yes. Fabric Planning supports Excel as a starting point in two ways.

In PowerTables (Data Management), you can upload an Excel spreadsheet and load it directly into a table. This is useful for getting reference data, chart of accounts, or any structured data into Fabric quickly.

In Planning sheets, you can use an Excel file as your starting point for building a plan. You also have the option to import from an existing Power BI semantic model instead, which lets you build on top of data your organization has already invested in.

To be clear: this is not a bi-directional sync with Excel. You can start from Excel, but the entire idea is that you move the data entry into Fabric where it happens in a fully audited manner. Once you have uploaded your starting point, the planning work lives in Fabric. You can absolutely link Excel back to see the final numbers through Fabric mirroring and connections to pull updated data back into Excel, but the data entry moves up into a governed, auditable environment. That is the upgrade.

No. The semantic models behind your PowerTable, Intelligence and Planning sheets run on your Fabric capacity, and the people working in those sheets are not opening a Power BI report, so they don't need a Power BI Pro license. Each person holds a planning session instead: Viewer, Stakeholder or Planner. That holds below F64 too, where a consumer can read Intelligence sheets on a Viewer session rather than buying Pro. Classic Power BI reports and dashboards still follow Power BI's own licensing rules.

A note on semantic models: if you are connecting Fabric Planning to a Power BI semantic model, the original author of that semantic model would need a Power BI Pro license to build and maintain it. That is a Power BI requirement, not a Fabric Planning one.

Fabric Planning runs on Fabric capacity. That is where you pay.

Yes. Fabric Planning comes with a full built-in audit trail at the cell level, row level, and column level. You can see who changed what and when without writing any code or going behind the application.

This is not something you configure or build yourself. It is part of the product. Every change is logged automatically. For anyone who has ever sat in a board meeting and heard “I did not put that number in,” this is the answer.

This was one of the reasons Lumel’s offerings became popular in the Power BI ecosystem compared to other writeback solutions. The audit history was built in from the start, and it carries forward into Fabric Planning.

Fabric Planning inherits row-level security (RLS) from your Power BI semantic model. If you have already set up RLS on your semantic model, you do not have to configure it again. Fabric Planning respects it automatically.

On the data layer side, the Fabric SQL database that stores your planning data should sit in a separate workspace with its own security controls. Business users should not have direct access to Fabric SQL, the same way you would not give business users direct access to your ERP or CRM database. They interact with the application layer. The data layer is governed separately.

OneLake security is not yet fully applicable to this scenario. As of today, it only works with Lakehouses at GA. This is something to watch as it matures, but it does not block you from securing your planning environment today using RLS and workspace-level controls.

Planning is available in every Azure region that supports all Fabric workloads. Some regions are Power BI only and run no Fabric workloads, so check your capacity's region on Microsoft's Fabric region availability page.

If you do not see Fabric Plan in a supported region, make sure Fabric Planning is enabled in the tenant admin settings. That is the most common reason it does not appear, even in regions where it is available.

Yes. Concurrency is supported in Fabric Planning. Multiple people can be in the same plan working at the same time, just like Excel.

The thing to understand is that, also like Excel, the last person to edit a cell wins. If two people update the same cell, the most recent change takes precedence. The good news is that Fabric Planning has a robust cell-level audit trail, so if a collision happens, you can see exactly who changed what and revert if needed.

Best practice is to implement row-level security (RLS) to reduce the chance of collisions in the first place. Give people access to the parts of the plan they own, and concurrency conflicts largely take care of themselves.

Fabric Planning writes back to Fabric SQL. That is the destination by design.

This makes sense because Fabric Planning is built natively on the Microsoft Fabric backbone. Fabric SQL is the natural target inside that ecosystem, and it supports automatic mirroring to OneLake, which means your planning data is immediately available across other Fabric items.

If you need the data outside of Fabric, like in an external data warehouse, Snowflake, or another platform, you use the standard Fabric capabilities to move it. Microsoft provides interoperability for these scenarios. You do not need to push data out of Fabric Planning directly, because once it lands in Fabric SQL, it is already part of the broader Fabric ecosystem you can share from.

No. Fabric Plan is not embeddable outside of Fabric at this time. It lives inside the Fabric experience.

There are other elements of Fabric IQ that can be consumed outside of Fabric (for example, Fabric Data Agents can be used in Copilot Studio), but the planning workload itself requires the Fabric environment.

Just like Excel. When you enter a formula into a cell, Fabric Planning stores the formula in the application, not the resolved value. Click on a cell, and you see the formula or the value you entered, exactly as you would expect.

This is what makes the planning experience powerful. When the underlying actuals refresh, formulas you have built on top of them refresh live too. You are not stuck with stale calculations the moment your source data updates.

A note on inputs: scaled numbers (anything you type as a millions or billions abbreviation, for example) are taken as plain inputs, not interpreted as formulas. Formulas are formulas, values are values, and the application keeps the distinction clean.

The best way to understand this is to play with the application yourself. Once you do, the behavior feels familiar to anyone who has worked in Excel.