Fabric Planning: What, So What, and Now What?
Why should I care about Fabric Planning?
A Story From 2016
Let me take you back to September 2016. I had just finished a budget cycle at a publicly listed company with a global footprint and multiple ERPs. By Excel standards, what we had built was as good as it gets. Centralized files. Interconnected workbooks. Templates flowing in from every business unit. Audit trails. The depth behind every number was there. The business was happy. Compared to where we had started, this felt like a finished product.
Then the leadership team came to me and asked the question every FP&A person dreads: “What happens if we do this? What if we do that?”
To create a single forked version of the budget, I had to manually duplicate every linked workbook, rebuild the connections, recompile everything, and pray nothing broke in the chain. I quoted them two weeks per scenario. They were thrilled. “Only two weeks?” After three months of budget cycle, two weeks felt like a miracle.
I remember standing there thinking, “Two weeks. To manually rebuild a forecast. Where one broken link can cascade through the entire model and lose hours of work.” I was solving the problem with my hands, not with the tool. There had to be a better way.
After the budget season ended, I convinced my CFO to send me to a conference in Boston that September. We had an odd fiscal year that ended in July, which is why I could finish budget and travel in September. That is where I first saw Power BI. And here is the part most people get wrong about my story: I was not impressed by the BI. I was curious if I could do planning potential in there.
I went home and started researching writeback tools that would let me plan in Power BI. I will be honest, my motivation for learning Power BI was 80 percent planning and 20 percent reporting. I started in October. My budget was due again the following year. I had six months to figure it out, and most of that time was spent realizing that to plan in Power BI, I needed my data in a structured format first. So I built the data foundation. Then I built the planning model. We ran our 2017 budget on Power BI using the only writeback tool I knew about at the time.
A side note that matters: my Power BI project, at roughly one-eighth the budget of the SAP Analytics Cloud project running in parallel, killed that initiative. Inside the company, I became famous for the BI work, not the planning work. The planning was the side benefit. It was always supposed to be the main course, but the optics flipped because reporting was easier to demo. That is how my accidental data career started.
Why am I telling you this story? Because what Microsoft announced at FabCon Atlanta this year is the closing of a fifteen-year loop for me. Planning has officially gone native in Microsoft Fabric. The thing I tried to build by hand in 2016 is now a first-class capability in the data platform. Let that sink in. And I want to walk you through what it is, why it matters, and what you should actually do about it.
The Why: Planning Has Been Stuck for Twenty Years
Before we get to the announcement, let us be honest about where planning has been.
The headline number you will hear is that seventy percent of planning still happens in Excel. I think that is an underestimate. Even companies that have implemented full EPM platforms are still doing significant chunks of planning in Excel. Excel is the largest EPM tool on the market, full stop. The reason is not that finance teams are stubborn. It is that every alternative has demanded the same trade: hand the process over to IT, hand it over to a consulting firm, hand it over to a technology team, and lose ownership.
Consultants are not the problem here. The problem is that traditional EPM technology is so complicated that the business cannot be involved in running it. Once you implement it, finance becomes a customer of its own planning process instead of the owner of it. Every change request becomes a ticket. Every model update becomes a project. The agility of Excel disappears, and what you get in return is a system you do not control.
Power BI changed this for reporting. It pulled BI out of IT and put it in the hands of business people. I am a living example of that shift. Fabric Planning is about to do the same thing for planning. That is why this matters.
The What: Fabric Planning, Explained
Let me cut through the marketing language.
Fabric Planning is a native Fabric workload. It is not a connector. It is not a bolt-on. It is not a third-party tool that writes back to Fabric SQL and calls itself integrated. It ships as a first-party Fabric item called Fabric Plan, which lives inside Fabric IQ. Microsoft has confirmed it as a first-party item. It runs on your existing Fabric capacity, inherits your Fabric security model, and you do not buy anything separately to use it.
The technology behind it was built by Lumel, a company that has spent over a decade developing planning capabilities on the Microsoft platform. Microsoft licensed Lumel’s IP and integrated it natively. If that makes you uneasy, think about Microsoft Copilot. Copilot is powered by OpenAI. Nobody calls it a third-party product. Same model here. Fabric Planning is Microsoft. Lumel built the engine. You will not interact with Lumel as a vendor.
The simplest way to understand Fabric Planning is to think about Office. You do not think twice about opening Excel because you already have Office. You do not buy Word and PowerPoint separately, you do not run a separate procurement cycle, you do not negotiate a new contract. They are just there. Fabric works the same way. If you already have Fabric, you already have lakehouses, warehouses, semantic models, and the data foundation to support them. When you want to roll out Fabric Planning, that is it. You enable it. Your data is already there. Your models are already there. You just add another workload. This simplification is, in my opinion, the most underrated part of the entire announcement.
When you create a Fabric Plan item, you get three integrated capabilities. Each one is organized around a different type of “sheet.” Yes, sheet. Some things never change.
Planning is the core budgeting and forecasting engine. Multi-dimensional models, top-down and bottom-up workflows, rolling forecasts, scenario modeling, version control, cell-level commenting, multi-role workflows, governed approvals. Plans write back to Fabric SQL automatically.
Intelligence is the variance reporting and analysis layer, built on Lumel’s ten-plus years of developing financial visualizations. You see plan versus actuals in a single reconciled view, with variance measures calculated automatically. IBCS-certified financial reporting. Ad-hoc analysis for business users.
Data Management, formerly known as PowerTable, is the part closest to my heart and probably the most universally applicable. It manages your forward-looking reference data: projected customers, planned products, future cost centers. It is also a no-code app builder for structured workflows, with row and column-level access control, approval routing, and one-to-one sync to Fabric SQL. The presentation Gopal and I used at our launch event included a slide that just said “START HERE. Replace every lookup table you manage in spreadsheets today.” That is exactly right. Every organization has dozens of these. Data Management is the easiest, lowest-risk way to get value out of Fabric Planning today.
All three capabilities can be used together as a full planning suite or independently. You do not have to adopt everything at once.
The So What: Why This Matters
This is where I want to slow down, because the “so what” is where most people will either get it or miss it entirely.
The Wall Between Data and Planning Just Came Down
For anyone in finance, the most important thing about this announcement is that the wall between “where your data lives” and “where your plans live” is gone. Actuals, budgets, forecasts, and variance analysis are now flowing through the same platform, governed by the same security model, powered by the same engine. No more reconciliation between your planning tool and your reporting tool. No more version control chaos. No more waiting for IT to build a bridge between two worlds that should never have been separate.
If you have lived through a planning cycle where the close numbers and the forecast numbers did not tie because two different systems told two different stories, you know exactly why this matters.
Finance Can Own This
This is the part I want senior FP&A practitioners and finance leaders to hear clearly. Fabric Planning is positioned to do for planning what Power BI did for reporting. It is a tool finance can own. You will probably need help for production-grade, enterprise-wide rollouts. That is true of any serious capability. But for the simple stuff, the day-to-day building, the experimenting, the prototyping, you can get your hands dirty yourself. You do not have to hand it over to a consulting firm just to find out whether it works for your business.
I have spent fifteen-plus years watching finance hand over ownership to technology teams every time we adopted a new EPM tool. Fabric Planning is the first credible exception.
The Pricing Model Breaks Traditional EPM Economics
Fabric Planning follows the same all-inclusive pricing as every other Fabric workload. There is no separate license, no per-user fee, no SKU to negotiate. It consumes Fabric capacity units, smoothed over thirty days.
Here is what this breaks. With traditional EPM tools, if you have two hundred budget contributors who only enter data for three months a year, you are still paying for two hundred licenses for all twelve months. With Fabric, you only consume capacity when those users are actively working. You can scale capacity up during budget season and scale it back down when the cycle ends. You pay for what you use, when you use it. For anyone who has fought a procurement battle to justify license counts that only matter for one quarter, this changes the math entirely.
If You Already Did the Hard Work, You Are Already Ready
The CFOs I want to talk to most are the ones who have already lived through a failed EPM implementation. Many of my customers tried to implement EPM first, failed, and then rebuilt their data foundation properly with Power BI and Fabric. They cleaned up their data models. They invested in semantic layers. They built the discipline.
For those organizations, Fabric Planning is essentially free. The investment they made in their data foundation suddenly unlocks planning as another workload on top of what they already paid for. No second deployment. No second procurement cycle. No second integration headache. The work you already did was not wasted. It was the prerequisite. Now you get the planning capability that the failed EPM tool was supposed to deliver, on top of the data platform that actually worked.
The Architecture Is Different From Anything That Came Before
Every previous Power BI planning solution, including Lumel’s own earlier offerings, followed the same pattern: a custom visual built on the Power BI SDK, connected to a separate modeling engine, writing back to Fabric SQL or another database. None of those custom visuals were certified by Microsoft. From a security and CISO perspective, that was always a real challenge. An uncertified visual could technically send data anywhere.
Fabric Planning is not a custom visual. It is a native Fabric workload built from the ground up, without the limitations of the Power BI SDK. The application and the data live in the same platform, secured and certified by Microsoft. RLS is inherited from your semantic model. Audit trails are built in at the cell, row, and column level. This is a fundamentally different architectural foundation than anything that came before.
Your Data Foundation Is Now the Bottleneck
This deserves its own section, because it is the most important sentence I can say to a finance audience: the technology is no longer the bottleneck. Your data foundation is.
Fabric Planning is only as good as the data it sits on top of. If your actuals are messy, if your chart of accounts has inconsistencies, if your dimensional structures are not clean, no planning tool will save you. You cannot skip the maturity curve. You cannot bypass the data foundation. It is the prerequisite for everything else.
If you have been doing things in a haphazard way in Excel, Fabric Planning is not going to magically fix that. Step zero is getting your data foundation right. If you do not have one, that is the first project to start. If you have one, you are ready.
This is also why I think this is the most exciting moment for finance teams in twenty years. The technology has caught up to where finance has wanted to be for decades. The only question left is whether your data is ready for it.
The PerformancePoint Question
I cannot write this article without addressing the elephant in the room. Microsoft has been here before, and it did not end well. PerformancePoint Services was deprecated. Firms that built FP&A practices around it were left scrambling. That history is real and people remember it.
So why is this different?
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 also matters how this was launched. Microsoft did not announce this as an ISV offering or a partner solution. It was announced as Fabric Planning, with a small “powered by Lumel” note. That positioning tells you where this is headed.
There is also the team behind it. Fabric Planning has a dedicated development team that is focused entirely on planning. They are not competing for resources with twelve other Microsoft initiatives. They are not subject to changing internal priorities. That focus means faster iteration and less risk of the feature stalling.
And then there is Lumel itself. A couple hundred employees, seasoned through SAP, who had the planning technology but needed a platform that was ready for it. Power BI gave them the adoption path. They won the Best Overall EPM Vendor award in 2025 and the Financial Modelling Innovation Award in 2020. Fabric completed the picture. Microsoft took time to vet Lumel before making this the native planning solution. They chose a team and a product that had already won the market.
Finally, consider the adoption flywheel. The path from Excel to Power BI to Fabric to Fabric Planning is a natural progression. There are over twenty million Power BI semantic models already in production. 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 any of this guarantee permanence? No. Nothing in technology is guaranteed. But the strategic importance of Fabric, the dedicated team, the adoption flywheel, and how Microsoft chose to position this all point in a very different direction than PerformancePoint.
Will This Replace FP&A Jobs?
I want to address this directly because it is in the back of every reader’s mind.
Fabric Planning is going to make FP&A jobs better, not replace them. If your job today is making Excel files and pushing papers, then yes, that part is going away. But that was never the value-added part of the role to begin with. The work that actually matters, the judgment, the analysis, the scenario thinking, the business partnering, gets amplified, not replaced. The FP&A professionals who lean into this will become more valuable, not less. The ones who treat their job as defending a spreadsheet are going to have a harder time, but that was true before this announcement too.
A Fair Devil’s Advocate
If I were arguing against adopting Fabric Planning right now, here is what I would say.
First, it is in preview. As a general rule, you do not put production workloads on preview features. So at the moment, you experiment with it. You build a sandbox. You prove out a workflow. You do not migrate your annual budget to it next month.
Second, if you already have an EPM tool that works well for you, and you are not drowning in unmanaged Excel chaos, do not change. The cost of change is real: migration effort, retraining, rebuilding models, disruption to a planning cycle your business depends on. Working solutions do not get replaced just because something new exists.
Both of those are honest cautions, and they should temper how aggressively you move. They should not stop you from paying attention.
My Background, So You Know Where I Am Coming From
I started my career around the era of legacy EPM tools: Hyperion, Cognos, BPC. To be clear, I do not have direct experience implementing those legacy tools myself. My exposure to them was as an FP&A practitioner using them, not as the person standing them up. The closest I came was when my company implemented BPC for consolidation, and the consulting partner advised us to use a different tool entirely for planning. That advice, in 2016, is what cracked open the Pandora’s box that started my Power BI journey. It is also what told me everything I needed to know about the state of legacy EPM tools at the time.
I know about One Stream and a handful of newer EPM platforms but have not personally implemented them. On the Power BI EPM tool side, that is where I have actual hands-on experience. I wrote the FP&A Market Guide reviewing five tools, and I implemented three of those five before I left corporate and founded Data Crafters.
All of those tools, in their own right, are good. I am not here to throw any of them under the bus. But Fabric Planning changes the game because the friction of selection disappears (you are already on Fabric), the storage and integration are simpler, and the scaling story is fundamentally different. The “this is just another planning tool” frame misses the point. It is not. It is a planning capability that lives where your data already lives.
The Now What: What You Should Actually Do
I want to be careful here, because the right answer depends on where you are starting from.
If you are already on Fabric and have a clean data foundation: enable Fabric Planning in your tenant admin center. Try it on a Fabric trial capacity if you do not want to use production capacity yet. Pick one focused use case. I would start with PowerTables (Data Management) and replace one lookup table you currently manage in a spreadsheet. That is the lowest-risk, highest-value entry point.
If you are on Fabric but your data foundation is rough: do not start with Fabric Planning. Start with your data foundation. Clean up your chart of accounts. Get your dimensional structures right. Build your semantic models. Then come back to Fabric Planning. Without good data, no planning tool works. This is not a step you can skip.
If you have a working EPM tool today: do not migrate yet. Watch the space. Read the FAQ on fabricplanning.io. Follow the content. If the components I mentioned above (Data Management and Intelligence) could solve a specific pain point alongside what you already have, experiment with those without ripping anything out.
If you are evaluating planning tools right now: put Fabric Planning on the list. Even in preview, the architecture and the trajectory are too significant to ignore. The total cost of ownership story is fundamentally different from anything else on the market.
If you are a senior FP&A practitioner trying to figure out what to do on Monday morning: start by following along. Subscribe to the Fabric Planning Substack and the FAQ on fabricplanning.io. Fabric Planning is new. Things are changing weekly. The single most valuable thing you can do right now is build the curiosity habit. Open it up. Tinker with it. Break it. Run a small experiment. By later this year, you will be the person in your organization who can speak credibly about whether this is right for your team. That is a valuable position to be in.
Closing Thought
People who have followed my career sometimes ask why I switched jobs. The honest answer is that I never did. I went deeper into FP&A, not away from it. The opportunity took me from finance director to chief data officer, and eventually to founding a company that specializes in implementing data analytics end-to-end on the Microsoft stack. If you go back and check my roots, I never left FP&A. I still hold my CMA and FPAC certifications. I still serve on FP&A advisory boards. I still think of myself as an FP&A practitioner who happens to have spent the last decade building the data foundation that planning was always supposed to sit on.
And now my journey has brought me back to where I started. Planning. Except this time, I am not stitching together workbooks at 11 PM trying to fork a budget. This time, the platform is built for it.
That is what makes this moment personal for me. It is not just another product announcement. It is the closing of a loop that started in 2016 with a frustrated finance director in a conference room in Boston, asking himself if there was a better way.
I am cautiously excited about Fabric Planning, and I think you should be too. Cautiously, because it is in preview and the data foundation work is still on you. Excited, because the architecture, the pricing model, the ownership story, and the trajectory all point in a direction finance has been waiting twenty years to see.
I sat down with Gopal Krishnamurthy, the founder and CEO of Lumel, to talk about all of this in detail. We walked through the architecture, the components, the demos, and the questions we knew people would have. You can watch the full session below.
The FAQ on fabricplanning.io is being updated regularly as new questions come in. I will keep writing here as the capability evolves. This is the central place I am pushing all of my Fabric Planning content and analysis going forward.
Pay attention to this one. It matters.