Sign in
 Resources · FAQ

Frequently asked Questions

This FAQ addresses common questions and clarifications that arise while working with plan. It covers environment setup and interface navigation.

Product & positioning

There is nothing to buy separately, no separate vendor contract, and no additional licensing. Fabric Planning ships as a first-party workload inside Fabric IQ called “Fabric Plan.” Microsoft has confirmed it as 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.

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. You buy it from Microsoft, you use it inside Microsoft, Microsoft supports it. Fabric Planning works the same way.

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

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. Microsoft did not announce 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. Unlike features built by Microsoft’s internal teams that compete for resources and shift with changing priorities, 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. Microsoft took time to vet Lumel before making this the native planning and writeback solution. They chose 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 definitely not right now just because something new exists. Fabric Planning is currently in preview. Making a migration decision based on a preview feature is premature.

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.

When Fabric Planning moves to general availability, the decision becomes 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.
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.

Pricing & billing

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). Consumption varies based on user type: Planners (authors, modelers, and admins), Stakeholders (data entry, approvals, comments, and writeback), and Viewers (view and interact locally). That consumption smooths over a 30-day period. Background automation jobs (planning-sheet syncs, PowerTable flows) are the one addition: they bill per successful run, about 2 CU-hours each, against the same capacity. You can get started with as little as an F2 capacity to try it out, though production deployments realistically start at F4, and higher workloads require more. 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. You pay for what you use, when you use it.

To size your own deployment by role, use the capacity and cost calculator.
A sustained CU is a seat license. The first time a user acts in a role, they consume a 30-day license for that role, and that license 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. Sustained CU is different: it is a continuously-held seat license 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.
Billing starts when a session opens, and your role is set by what you do in it. Users start at the minimum, Viewer, when a session opens. The system upgrades them automatically as they take higher-privilege actions: data entry or write-back moves them to Stakeholder, and authoring, modeling, or admin actions move them to Planner. A user who holds multiple roles is billed once, at the highest role only. A role upgrade starts a new 30-day window at the higher role, and once a window is triggered it is a billing commitment: the full 30 days are incurred even if an admin closes the session early.

For what each role can do and who should hold it, see the roles page.
A Viewer session: 0.05 CU held for 30 days, under $7 at US list rates. The peek is cheap. The upgrade is what to govern: entering one number turns that Viewer into a roughly $30 Stakeholder session, and touching the model opens a roughly $150 Planner session. Microsoft's own wording, "opens or meaningfully engages," leaves a bare peek slightly ambiguous, so treat any open as billable until told otherwise.
No cap. Within the 30-day session the role charge is fixed no matter how much you do: dozens of PowerTables, a hundred scenarios, thousands of edits, and the rate doesn't move. What scales with usage is the compute underneath, drawn from the Fabric capacity you already own; the seat itself stays fixed. That flat charge covers every artifact and unlimited activity across Planning Sheets, PowerTable Sheets, and Intelligence Sheets, for whatever role you hold.
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. The window runs out either way, at the rate it opened at. Cost control happens before the click, by governing who gets access to which role in the first place, not by managing sessions after they've started.
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.
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).
Pausing, resizing, or deleting a capacity closes the books on every open session: the remaining days of each 30-day window bill out immediately instead of burning down over time. A restart is a pause plus a start, so the true-up rides along, but it is not a second charge. When the capacity comes back, users burn down the hours already billed, and no new session opens until the original window would have ended. A restart accelerates the bill; it does not grow it. Confirmed directly by the product team; this true-up billing behavior is rolling out in early August 2026.
Yes. Sessions key on the user plus the capacity, so one person active on two capacities opens two separate sessions, one on each. Confirmed directly by the product team.
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.
Traditional EPM tools charge annual per-seat licenses, 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 post does not address it.

Getting started

Fabric Planning is in preview. As a general rule, always be cautious about putting production workloads on preview features. That said, not all three components are at the same stage of maturity.

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 even if the Fabric-native packaging is still in preview.

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.
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 user type (Planner, Stakeholder, Viewer) has a different consumption pattern, and that consumption smooths over 30 days.

The real question is not “is my capacity big enough” but “how many people will be using it concurrently.” 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.

Technical & security

No. Fabric Planning does not require any Power BI Pro license. The planners, stakeholders, and viewers working inside Fabric Planning are using Fabric artifacts, not Power BI artifacts.

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.

Fabric Planning (Plan preview) is available in most Fabric regions but not all. Some regions do not yet support it during preview.

For the current list of supported and unsupported regions, see the official Region availability for Plan (preview) page on Microsoft Learn.

If your capacity is in a region where Plan is not yet available, you will not see the option to create a Plan item in your workspace. Microsoft has said broader regional availability is coming as billing meters roll out region by region; check the Learn page above for the current list rather than a fixed date, since preview rollouts shift.

If you do not see Fabric Plan in a supported region, make sure the preview feature is turned on from the tenant admin center. 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.
Fabric Plan
Enterprise planning, Integrated with PowerTable and Intelligence, native to Microsoft Fabric. Co Engineered with Lumel.
BUILT ON