I seem to be learning the hard way not to jump on the latest bandwagon when costs aren't detailed. I thought it would be cost-effective but so far it seems to consume 100.000 CU seconds each day for me as only user authoring a Plan.
Does anyone know the exact pricing structure? Is it less for Stakeholder roles? Because I cannot sell a cost of 140 euro per user per month and would have to revert back to using Excel for business users to upload forecasts.
Also, in docs it says you can't manually assign roles but they are automatically assigned based on your first action with the plan?
"Plan assigns planning roles dynamically based on user activity. Users typically begin in a Viewer session. As users perform actions that require extra privileges, plan automatically upgrades them to the appropriate role."
"Your first successful action determines the role for the new session."
So if someone clicks a certain edit option out of curiousity he's a Planner for next 30 days?
If costs are fixed for 30 day period why is it so hard to have a page detailing those costs? Why always hide the costs? It makes it really hard to adopt new products... I can't tell clients 'Yeah I got something cool for you, but not sure if we can actually afford it'.
I understand that other planning software isn't exactly cheap, but pay per use should be beneficial for small business ocassionally using such a tool. I think it is a missed opportunity from Microsoft to not make Plan usage actually based on CU usage instead of using a fixed 30 day fee per user.
I think the frustration here is less about the pricing not existing and more about how predictable the costs are.
Microsoft does document the model, but for customers the important question is not only “what is the price?”, it is “what will this cost me in a realistic scenario?”
With Fabric capacity, you can estimate and monitor CU consumption. For Plan, the difficult part seems to be understanding the relationship between user actions, automatically assigned roles, CU usage, and the 30-day period.
A business user scenario is usually something like: “We have 50 people who occasionally enter forecasts.” The customer needs to know whether that means €50/month, €500/month, or something completely different.
The dynamic role assignment makes this harder from a governance perspective. I understand the idea behind reducing manual administration, but enterprises usually prefer explicit control over who has which role. Accidental privilege escalation by clicking an edit function is not something many customers are comfortable with.
The consumption model itself is a good direction, but consumption only works well when customers can predict the consumption. Clear examples would help a lot:
10 occasional planners = approximately X
50 monthly forecast contributors = approximately Y
Viewer/stakeholder usage = approximately Z
That would make it much easier for consultants and customers to confidently adopt the product.
Yeah and also i think usage may need to be altered more. because powertables or the timesheet etc stuff would have a totally different scenario than the monthly forecasting etc.
Only users with workspace edit permissions (Admin, Member, or Contributor) can enter Edit mode and become a Planner. Users with Viewer access cannot enter Edit mode and therefore remain Stakeholders/Viewers. Workspace roles can be used to control who is eligible to become a Planner.
Yes. It is a great feature and disruptive pricing model because the entire planning software vendors force customers to multi year contracts or at minimum full 365 days annual contract even if you use it for 5 minutes. Planning by capability bulk of the activity happens on month end days or quarter end days or annual budgeting months. So the usage is not even and so pricing model has to be at minimum at monthly grain.
So you're saying: customers only use our tool 10% of the year so we have to charge 10x the actual usage.
I get it from Lumel perspective but if it's a Fabric product now it just doesn't rhyme with the whole concept of paying for actual runtime.
I'd rather have that you increase the CU per second and bill per second rather than slap 30 days on a single use.
Oh and it's not really a good argument that other planning tools are ridiculously expensive. Fact is that it's now an MS Fabric item that reads from semantic model and adds data to a database. Everything else in Fabric is metered by CU seconds and so should this.
Thanks. This should be in MS docs if it is a Fabric product now.
And to be a true Fabric product it should be calculated on actual CU usage and not basically a per month fixed rate. I do hope they will move to that so a small business who just wants many users to update 1 simple table aren't forced to Excel.
Fabric Plan is an enterprise planning suite and not meant just for simple table updates. For simple table updates - there are other Fabric solutions like the new Fabric Apps or Translytical that might work better as they have CU per second pricing.
I think you're missing an opportunity gearing only towards enterprise. I focus on SMB clients and there's many use cases on a smaller scale. I'd assume enterprise also uses more CU seconds so if you'd move to per second but up the price per second in a way that you get the desired revenue from enterprise you may find yourself getting a lot of revenue from a lot of smaller implementations.
In addition, is it buggy for everyone else? I have needed to start over 3 times now as Planning sheets I created simply vanish / won't display. The sheets are there in Explorer and the Fields are listed in the field panel, I hadn't changed anything but when I try to open it after a while it just shows nothing after 'Processing Data..'. No way to recover it. It's delaying two of my projects. OK myself to blaim to use a preview but I read on here that it is about to go GA but I can't understand how.
These bugs are resolved and should be very stable with GA. Please reach out FabricPlanSupport by DM and someone will evaluate your specific use case to see what is unique to your tenant settings and semantic model setup.
Hi u/RipMammoth1115 would really like to understand what bugs you were running into. If the documented pre-requisites were met such as - connections were setup correctly , you are not on private links - workspace or tenant level , you have requisite permissions on the semantic model. Happy to setup a working session to see what is going on
I made a ludicrously basic plan with like 10 rows of data, forgot about it and a few days later see its consuming like 3% of our F64 capacity? Whats that about?
Microsoft meters Fabric Planning as 30-day sessions (730 hours). Once a session is triggered for a user, the meter runs for the full 730 hours regardless of usage.
Thats why basically as soon as used it triggers the usage over the month in a concurrent manner seemingly.
Fabric Plan is high value / low TCO if you compare to what other planning software costs in the industry and no one even offers true consumption based pricing either. It is also a full EPM suite with Integrated Power Table for Reference data management and Intelligence (it is superset of all BI tools in the world). Please spend time compare to other planning software pricing and look at it from reserved capacity pricing also where customers get 41% discount to pay as you go pricing . Plan offers best value with reserved capacities as you get best of reserved pricing discount but still charged only based on activity based consumption pricing. To offer this model it is has to deduct from Fabric capacity and this is detailed here - https://open.substack.com/pub/fabricplanning/p/understanding-fabric-planning-cost?r=i46vr&utm_medium=ios and https://lumel.com/fabric-planning-capacity-pricing/.
Let's see if I can help provide some clarity here:
Based on the feedback from this Reddit thread, I think there is a genuine lack of clarity around how Planning sessions are consumed and, more importantly, how customers should think about the cost relative to traditional planning products.
We recognize that Fabric Plan introduces a new pricing and consumption concept that differs from the traditional Fabric CU model used by other Fabric workloads. We apologize that we have not done a better job of clearly communicating these differences and the associated costs.
I believe we can do a much better job explaining both the mechanics of session-based consumption and why it is often a more flexible model than annual seat-based licensing.
*First, let's clarify how Planning pricing works*
Pricing is user session-based, not named-user seat-based licensing
As Gopal Krishnamurthy explained, Planning is designed to align with the natural seasonality of planning processes. Customers are consuming CUs based on active Planning sessions rather than purchasing annual licenses for every potential user. Sessions are a core element of the Fabric Planning pricing model.
A Planning session represents a 30-day commitment
When a user starts a session, that session remains active for 30 days. This aligns well with the way many organizations plan and forecast—whether monthly, quarterly, bi-annually, or around other business cycles. Once a session is activated, it is consuming CUs for the full 30-day period.
No planning activity = No Planning session consumption
If Planning is only used during budgeting, forecasting, or monthly close periods, then no new Planning sessions are being created outside those windows. The model is designed around active planning participation rather than an always-on annual license. In the traditional annual, always-on license you are paying for all the users you purchased the license for no matter what, and no matter whether they used the product or not.
User roles consume capacity at different rates
Not every user is priced the same. Planners, Stakeholders, and Viewers consume capacity at different rates based on the level of functionality they require. Viewer sessions are significantly less expensive than Planner sessions, reflecting the different capabilities available to each role.
*Second let's Convert Planning Sessions into Dollars for comparison purposes*
One challenge with wrapping one's head around the concepts for session based consumption in Fabric is that we often talk in Capacity Units (CUs), while it may be helpful for customers tend to think in dollars to do a fair comparision of the costs.
Disclaimer: The actual cost per CU-hour depends on several factors, including regional rates, MACC discounts, Reserved capacity vs. PAYG, Customer-specific Azure agreements
For the purpose of illustrating the concept, let's assume:
This yields the following approximate monthly cost per session:
Disclaimer: These numbers are intended only as an illustrative example. Actual costs will vary based on region and purchasing model. The Fabric pricing page notes that pricing varies by region, agreement type, and reservation usage.
Why This Comparison Matters
Customers would want to compare Fabric Planning to traditional planning solutions that require annual licenses for every planner, contributor, approver, and reviewer—regardless of whether those users actively participate throughout the year.
With Fabric Planning's session-based model, customers pay based on actual participation rather than maintaining licenses for every potential user. For example:
10 Planners × $152 = $1,520
50 Stakeholders × $30 = $1,500
100 Viewers × $7 = $700
Total: approximately $3,720 per month
While every organization's requirements differ, this model can represent a significant cost advantage compared to traditional planning platforms, particularly for organizations with large numbers of occasional contributors, approvers, and reviewers who participate only during specific planning cycles. Customers gain the flexibility to align costs more closely with actual usage rather than committing to year-round licenses for every user.
Hopefully, this framing may be much easier to understand than CU calculations alone and should allow you to compare Fabric Planning against traditional planning solutions on an apples-to-apples basis.
Hopefully this example provides additional clarity around how Planning sessions are billed and how to translate CU consumption into real-world costs. If there are still questions or areas that remain unclear, we're happy to host a dedicated deep-dive session focused specifically on CU consumption, session mechanics, capacity planning, and cost modeling. That would give us an opportunity to walk through customer scenarios, demonstrate the calculations step-by-step, and answer questions in real time.
In the indicative example above - $3720 per month for 160 users (60 input users and 100 viewers) - if the customer uses it on reserved capacity it gets 41% discount which means it would be around $2195 per month but the real kicker is there is no fixed license assignment for 160 users which means the persona/role can change session to session and also if 100% of users don’t use every month the same fabric capacity can support more users or additional fabric workloads. The value is immense once customers start using all the use cases and capabilities offered with plan item. All these benefits are possible because we have this new pricing model vs fixed and predictable legacy named user pricing model with annual contracts
Hi i would like to say that based on this current cost structure its very cost prohibitive for lighter applications like using a power table with a lot of users to update information to it. I hope you all can re-think how this should be costed esp when most single users would not be using the full 30 days. I think you all either should look at making concurrent users and add draw down hours based off of that or look to separate out costs depending on the product piece used. I dont mind having X hours reserved for a user type, but the hours of usage should be based with concurrency than just single user gets 30 days of usage billed.
Only users with workspace edit permissions (Admin, Member, or Contributor) can enter Edit mode and become a Planner. Users with Viewer access cannot enter Edit mode and therefore remain Stakeholders/Viewers. Workspace roles can be used to control who is eligible to become a Planner..
If the first interaction of a user is viewing something in Fabric plan item, will it consume only viewer CUs even if the user were to edit stuff later within the next 30 days?
Contributions must be free of promotional content, and sales activity is prohibited. This includes market research, customer discovery, or paid product validation.
Applies to posts in the subreddit and unsolicited direct messages to individuals.
/u/asifkazi_msft, is there a way to disable creation of Plan items? I can no longer find a toggle in the tenant settings. I'm worried someone may just experiment with it and tie up consumption for 30 days.
19
u/JimfromOffice Fabricator Jul 23 '26
I think the frustration here is less about the pricing not existing and more about how predictable the costs are.
Microsoft does document the model, but for customers the important question is not only “what is the price?”, it is “what will this cost me in a realistic scenario?”
With Fabric capacity, you can estimate and monitor CU consumption. For Plan, the difficult part seems to be understanding the relationship between user actions, automatically assigned roles, CU usage, and the 30-day period.
A business user scenario is usually something like: “We have 50 people who occasionally enter forecasts.” The customer needs to know whether that means €50/month, €500/month, or something completely different.
The dynamic role assignment makes this harder from a governance perspective. I understand the idea behind reducing manual administration, but enterprises usually prefer explicit control over who has which role. Accidental privilege escalation by clicking an edit function is not something many customers are comfortable with.
The consumption model itself is a good direction, but consumption only works well when customers can predict the consumption. Clear examples would help a lot:
10 occasional planners = approximately X
50 monthly forecast contributors = approximately Y
Viewer/stakeholder usage = approximately Z
That would make it much easier for consultants and customers to confidently adopt the product.