The whole rule

Planner, 1.16 CU. Create or edit the planning sheet itself, including telling it where it writes back to. That is the only thing on this list.

Stakeholder, 0.23 CU. Everything else. Create a PowerTable sheet, edit it, enter data into it. Create an Intelligence sheet, edit it, add data and use it. Comment, approve, run scenarios. And enter data into a planning sheet, which was always Stakeholder work and still is.

Viewer, 0.05 CU. Open a plan and look at it, and nothing else.

That’s it. Building is Stakeholder work now, unless the thing you’re building is the plan.

Figure 1. The rule on one card, if you want to send it to whoever owns your capacity. The middle band is the whole story. Until August 19, creating or editing a PowerTable or an Intelligence sheet put that person at 1.16 CU, and now it doesn’t.

What I clicked

I ran it in a trial workspace, watching the role indicator after every action.

Figure 2. Four rows of Stakeholder, then the flip. Everything above the last row used to cost 1.16 CU.

I had a plan artifact from before, so I started as a Viewer just by opening one, and that is where all your consumers of Fabric Plan sit. When I created the PowerTable sheet and connected it to the database I became a Stakeholder, and before Wednesday that would have made me a Planner. I became a Planner only when I created a planning sheet with a write-back destination.

What it changes

0.23 is about a fifth of 1.16, so the same PowerTable work runs at roughly $30 an active month at US list instead of roughly $152, or $18 against $90 on reservation. Nothing else moved. In Microsoft’s own words, there’s no new meter, no new rate, and no new SKU.

If you’re already running a planning cycle, your numbers don’t change, because your Planners were planning sheet authors already. What changes is everybody you were counting as a Planner because they maintain reference data. Count them as Stakeholders now, and if you’re standing up PowerTable on its own, you can provision a plan item with no planning sheets in it at all.

I’m updating the calculator and the roles page at fabricplanning.io early next week to match.

I’m super excited because I can’t think of anybody who doesn’t have this use case.

Planning in Microsoft Fabric IQ reached general availability on July 28, 2026, and billing started August 1, 2026. The persona change here was published August 19, 2026. My walkthrough was one session on a trial capacity, using the in-product role indicator rather than the Capacity Metrics app. Microsoft’s billing and roles pages on Microsoft Learn are both still labeled Preview, so verify with Microsoft before committing budget. Microsoft publishes no per-role dollar rate, so the figures here are derived from Microsoft’s published US pay-as-you-go capacity list prices and vary by region, and the reservation figures come from Microsoft’s documented reserved discount.

Sources: Billing personas for PowerTable within Planning in Fabric IQ (Generally Available), Supriya Kashyap, Microsoft Fabric Updates Blog, August 19, 2026. Roles in Fabric plan, Microsoft Learn. Earlier in this series: Understanding Fabric Planning cost and Fabric Planning went GA on Tuesday and the meter starts Saturday.

And there you have it. It is now in GA.

Dipti Borkar announced it Tuesday on the Fabric Updates Blog: Planning in Microsoft Fabric IQ is generally available, one suite with PowerTable and Intelligence. One sentence in that post matters more than every feature bullet around it. “Planning in MS Fabric billing will start on August 1st, 2026.” That’s Saturday. Everything this series describes has been free to run through preview, and in two days the meter turns on.

The rates came through GA unchanged: 1.16 CU for a Planner, 0.23 for a Stakeholder, 0.05 for a Viewer, the 30-day session. The sizing work is the same work it was on Monday, it just costs money now.

For fifteen years I bought planning software the same way, a per-seat license paid every month for a room full of people who used it hard for four months and barely opened it the other eight. This is the first pricing I have seen built around the way planning actually runs.

Aggressive or expensive

Part 1 went out last week and the feedback split two ways. One group thinks the pricing is aggressive, and they mean it as a compliment: a Stakeholder holds 0.23 CU, about $30 for an active month at list and $18 reserved, and the role charge does not move inside the 30-day window no matter how much they do. (Part 1’s FAQ got updated). The other group thinks it is expensive. The number they keep pointing at is the Planner: 1.16 CU, 58% of an F2, the smallest capacity you can buy. Build a model and more than half your smallest SKU is committed for thirty days, whether that model moves five records or a million.

Same rule, read from opposite ends. Until this week you could have that argument for free. From Saturday, one of the two readings starts showing up on somebody’s invoice.

The expensive argument comes mostly from data engineering persona, where efficiency means output per unit consumed, so a charge that does not scale with the work reads as waste. I hear it and I understand where it comes from. But metering raw compute gets planning wrong from the other side, because a manager keying a few numbers barely moves a meter even though those numbers are what make it a plan. Fabric Planning is priced as an EPM tool, not as compute.

One correction, because the objection usually lands on the wrong role. The person who enters ten records and gets billed as a Planner is the person who created the plan, and building that plan is what made them one, not entering ten records. Once it exists, the next person entering ten records into it is a Stakeholder, around $30. The 58% only opens when somebody touches the model itself.

Sizing starts with your org chart

Before you size anything, sort your people by what they do.

• Who changes the model, aka Planners

• Who changes the numbers, aka Stakeholders

• Who reads the result, aka Viewers

You can read more in Last week’s article on the roles and on sustained CU.

Your Planners are your FP&A or S&OP team, and there are never many of them. Stakeholders are the longer list, every manager who owns a budget or a forecast input plus salespeople if they enter their own numbers, and because that list grows with headcount it is the count to get right.

I sized this against a 2,200-person organization I knew from the inside, as its finance director. We needed about five Planners. Count the managers who own a budget or a forecast input and you land near 120 Stakeholders. Add sixty Viewers for leadership and reporting, and a cycle month comes to roughly 36 CU of role load before headroom.

A planning buffer of about 30% (my assumption, adjustable; it covers the database and processing overhead underneath the plan plus whatever else shares the capacity) puts you near 47 CU. That is an F64 during cycle months, running about three quarters full, with a quarter of the capacity still free for everything else on it.

Figure 1. My 2,200-person scenario in the live calculator: 5 Planners, 120 Stakeholders, 60 Viewers. 47.32 CU with the 30% buffer, an F64 at 74% full, which leaves 16.68 CU of headroom for everything else on the capacity.

The pattern holds at every size: Stakeholders are most of the bill, the Planners stay few, and that ratio is what you size against.

Figure 2. The three worked sizings: the CU each organization lands at with a 30% buffer, the F-SKU that covers it, and what that capacity runs per month at US pay-as-you-go and one-year reservation list rates. Capacity dollars are Microsoft’s published list prices and vary by region; the sizings are my planning assumptions, not Microsoft-published guidance.

One Planner alone occupies 58% of an F2, so the smallest SKU was never a production plan; the realistic floor for even a tiny FP&A-only deployment is F4. So, the pushback about running 58% of an F2, it was never meant for that.

Now put a dollar on it

Those F-SKUs have list prices, so we can leave CU behind and talk money. Now why do people think it’s aggressive?

Because a 500-person company could literally run an F16, even at pay-as-you-go, and pay about $25,000 a year for EPM capability. And that scale math holds at larger organizations.

Now the comparison a CFO will ask for, how does it compare to the market?

EPM vendors do not publish list prices, so I leveraged publicly available data rather than just speaking from my experience.

Vendr’s buyer data puts the median Anaplan contract in the low six figures, roughly $100,000 to $115,000 a year depending on the sample, with entry deployments in the $30,000 to $50,000 range.

For a mid-market 2,200-person company, run an F64 all year and you land near $60,000 on reservation, way under those medians. An SMB can start under $4,000 a year on reservation on an F4. The small enterprise on an F16, even holding capacity all year, lands around a quarter of a median deal.

These are procurement medians rather than published rates. Treat them as a range.

It’ll be interesting to see what people find out, once they have this calculator, about the gap between what they pay today and what Fabric Planning costs.

What GA actually added

The GA post changes what you are buying more than what it costs. Billing events now land in the Capacity Metrics app as production-ready metering, so from Saturday it shows actual charges, where a pilot in preview could only watch the CU draw.

It is the first time any of us can check this math against a bill. Planning, PowerTable and Intelligence are now formally one suite. And the automation surface got much wider: public APIs, CI/CD, deployment pipelines, service principal authentication, direct connectivity to Power BI semantic models and Fabric SQL, and Measure models and trees that build a planning model out of measures you already have.

That automation cluster is where I would slow down, because jobs bill per successful run. Automation volume used to be my honest shrug, since nobody outside your walls can guess it. In preview the automation surface was narrow. GA widened it, and the scheduled loads and recalcs you will wire up through those APIs are exactly the jobs that bill, so count them in the pilot the way you count Stakeholders.

Before the meter starts

Two days is enough time to sort your list. Not really, the main thing I would do before Saturday is to figure out the Fabric Planning artifacts. If you are tinkering with it, make sure you prepare to pay the bill going forward from August 1.

Healthy planning organizations have far more contributors and consumers than builders, so if your sizing comes out Planner-heavy, that is a process problem, and you found it before spending a dollar.

As Benjamin Franklin put it:

“Failing to plan is planning to fail.”

To make your planning easier, you can try the calculator at fabricplanning.io/calculator.

Bigger than the dollars: three to four weeks, down to about a week

Microsoft’s GA post quotes Rich Zielinski, Director of Finance & Treasury at Canlak Coatings, who says that moving off spreadsheets “transformed our forecasting process. What used to take three to four weeks of spreadsheets, emails, meetings and reconciliations can now be completed in about a week.” And now they have “simplified the process into a rolling forecast.”

Why is this personal? Canlak Coatings is a Data Crafters customer. We believe the proof is in the pudding, and that’s what we were busy with through the preview period.

What I want off the quote today is the cycle time, because it is the number this article has been missing. Three to four weeks of a finance team’s calendar, back to about one. The full study will be published by Data Crafters next week.

Final Take

I have done my analysis and made my decision, and I do not give advice where I have no skin in the game. My own company builds on this stack. I did not run the numbers in the abstract either. I ran them against the budget I used to sign as finance director of a 2,200-person organization. We were paying $120k a quarter for planning licenses and an F64 on reservation for a full year is about an eighth of that. So, from my finance background I agree the pricing is aggressive.

The way I read it, Microsoft is betting you will keep opening it and using it. I read that as a vote of confidence in how good they think the product is.

Which brings me back to Saturday. From August 1, the numbers above stop being a modeling exercise, so if you have a deployment running, sort your people by role and decide whether the capacity belongs on pay-as-you-go or on reservation, because Figure 2 prices the same deployment two ways.

Then stop looking at the cost, which is only part of the puzzle. I wrote it to give you real numbers, but what decides it is what the spend unlocks, and Canlak’s answer to that is a forecast cycle that used to eat weeks of a finance team’s year.

The seasonal case I opened with quietly assumes you plan a few months a year, the way finance always has. I doubt that survives. Volatility keeps rising, FP&A keeps moving toward rolling forecasts, and Rich’s team got there ahead of my argument, which is the turn showing up in a live deployment before I even finished making the case for it.

So, start with the process you already have, because that is the safe base case, and count past today’s budget owners to the people who would be in the plan once it runs every month. The version of always-on worth paying for is the one where the spend sits on something your people are inside every month, and the forecast in front of you is not three months old.

Size the tool by counting your managers, not your seats.

Subscribe now

Planning in Microsoft Fabric IQ reached general availability on July 28, 2026, and Microsoft states that billing starts August 1, 2026. As of publication Microsoft’s billing document for Planning is still labeled Preview, so the rates here are live-billing rates published in a preview-labeled document; verify current terms with Microsoft before committing budget. Microsoft has published no region statement and no Copilot or AI billing statement for Planning. Fabric capacity dollar figures are Microsoft’s published US pay-as-you-go list prices and vary by region; the reservation figures are derived from Microsoft’s documented reserved discount, and the per-role dollar figures are derived from published capacity rates, because Microsoft publishes no per-role rate. EPM contract figures are third-party procurement medians, not published list prices. Capacity scenarios are illustrative planning assumptions, not Microsoft-published sizing. Canlak Coatings is a Data Crafters customer; the quoted remarks are from Microsoft’s GA announcement.

Sources: Bring Enterprise planning to the AI Era with Planning in Microsoft Fabric IQ, Dipti Borkar, Microsoft Fabric Updates Blog, July 28, 2026. Billing for Microsoft Fabric Planning (Preview), Microsoft Fabric Updates Blog, June 2026. Microsoft Fabric capacity pricing, Azure. EPM contract benchmarks via Vendr procurement data for Anaplan, vendr.com/marketplace/anaplan. Nassim Taleb, “Skin in the Game,” Stanford eCorner. Companion explainer: Understanding Fabric Planning cost: three roles, three costs, one capacity.

Two people can read the same Fabric Planning documentation and walk away with opposite numbers in their heads. Some read the pricing as seat licensing in capacity-unit clothing: a Planner commits 58% of an F2 (the smallest Fabric capacity you can buy) for a month, whether that person works one minute or three hundred hours. Others expect a consumption meter, where the bill climbs while people work and drops when they stop. Both are half right, which is the tell that this pricing model needs a plain explanation.

This piece is my attempt to put it in one place, cleanly. Microsoft published the billing model in June 2026, ahead of anticipated general availability in July 2026, so the mechanics are on the record. What follows reflects the published preview terms, and I will update this piece if GA moves any of them. I am saving the sizing method and my opinions for Part 2.

One naming note before we start. Microsoft’s product name is Planning in Microsoft Fabric IQ, most of us say Fabric Planning, and I have seen it called Microsoft Plan in the wild. One product (the engine is built by Lumel), one pricing model, whichever name you heard.

The short answer: how Fabric Planning pricing works

Fabric Planning uses session pricing, a third model that sits between per-seat licensing and pay-per-use. Each user’s role holds a slice of your Fabric capacity for 30 days at a time, and a dormant month costs nothing. Three costs draw from one Fabric capacity: the people (priced by role), the overhead (the database and processing underneath), and the automation jobs. The session is the billing unit, and it exists only when someone shows up. Everything below is the detail.

Start with the roles

Every user lands in one of three roles, and the roles form a ladder. Each tier includes everything below it.

Viewer is read-only: open the plan, sort, filter, bookmark. Executives and anyone who consumes the result.

Stakeholders enter data. They write back numbers, create scenarios, approve, and comment. They work inside the model’s structure without changing it: they can enter numbers, but they cannot alter the model itself. Department heads, budget owners, and every bottom-up contributor live here.

Planner is in edit mode: build models, configure planning logic and rules, administer security and permissions. Your FP&A team, and almost nobody else.

You do not assign these roles up front. Everyone opens as a Viewer, and actions upgrade the role: enter a number and the system makes you a Stakeholder, touch the model and you are a Planner. Anyone holding multiple roles in the same capacity is billed once, at the highest role. You do not assign the cost; your users’ actions do. Governance is about controlling who can take which action. The full capability list sits on the roles page at fabricplanning.io/resources/roles.

Figure 1. The role ladder: who each role is, what each can do, the sustained CU each holds, and what that prices out to per active month at US list rates, all drawing from one Fabric capacity.

Cost One: your people, priced by role and session

The unit Microsoft prices in is the capacity unit, CU. Each role, while active, holds a sustained slice of your Fabric capacity:

Sustained means held: a continuous slice of capacity for the length of the session, like a reserved seat. Microsoft counts a session as 730 hours, an average month. The rates above come from Microsoft’s preview session materials and product-team confirmations; the billing post defines the model and publishes no rates.

Microsoft publishes no dollar price per role. It does publish dollar prices for capacity, so you can derive what a role costs: at US pay-as-you-go list rates, a Planner’s slice prices out ~ $152/$90 (PAYG/Reservation), a Stakeholder near ~$30/$18 (PAYG/Reservation), a Viewer under $7/$4 (PAYG/Reservation) for an active month.

Those three numbers are the per-person economics of the whole product, and the gap between $7, $30 and $150 is who is creating or editing the Planning Artifact vs entering data/comments/simulations vs someone who is only viewing.

How the 30-day session works

Now the session, because it settles the confusion this piece opened with. A session starts when a user opens or meaningfully engages with a planning item, and once it starts, its full 30 days are committed. The two readings from the top describe the same mechanics from different ends. Within an active month it behaves like a seat: the Planner’s slice is held for the window whether the work took a minute or a month, and closing the session early refunds nothing. Across the year it behaves like consumption: the off-season is free because dormant months never open a session. The windows chain by engagement, too: when one ends, the next touch opens the next one. So a Planner who works every month pays for every month they work, about $150 at list, and a user who goes quiet opens nothing until they return.

Two more mechanics matter. An upgrade mid-window (a Stakeholder who touches the model, say) opens a fresh 30-day window at the higher role from that day, and the lower role’s window stops accruing. A downgrade does the opposite of what people hope: the open window runs to its end at the higher rate. Both mechanics come from direct product-team confirmation, since the billing post does not spell them out. Activating a user is a 30-day decision. Know that going in, and it never surprises you.

Cost Two: the overhead

Every planning system I have deployed had two cost lines. The software was one. The other was everything underneath it: hosting, compute, storage, the database the system ran on. Fabric Planning has the same second line, and here that second line is your Fabric capacity.

The plan item’s data lives in OneLake. The moment a number is committed, it writes back to a SQL table in Fabric. The processing behind refreshes, calculations, and writeback draws CU from the same capacity your roles draw from. Microsoft’s billing post covers this in one line: planning “runs on Fabric Capacity, consumes existing Fabric CUs,” one unified pricing model in their words. It does not itemize the overhead further. So the honest way to carry it: the overhead is real, it lands on capacity you already own rather than on a separate invoice, and nobody outside Microsoft can hand you its exact size for your workload today. In preview you can already watch planning’s draw in the Microsoft Fabric Capacity Metrics app, so a pilot can measure the overhead directly.

Until GA hardens the numbers, treat overhead as headroom. The calculator I built at fabricplanning.io models it as a buffer percentage you set yourself. I default to 30%: an assumption, and one you can adjust. A pilot on your own data is the only measurement that counts.

Cost Three: the automation jobs

The third line covers work no human is present for: data syncs across models, updates to connected planning sheets, the scheduled machinery. These run as jobs, and Microsoft bills them at a fixed cost per successful job. As I understand it today, each job draws about 2 CU-hours from the same capacity everything else uses (call it thirty-odd cents a job at the same US list rate, derived); treat that figure as informational until GA, because the preview materials it comes from were labeled illustrative. The wording is per successful job, so a failed run should not bill; I have not seen that tested.

The number nobody can give you yet is job count. How many jobs does a real deployment run in a month? It depends on how much syncing your model does, and the only good answer comes from counting them in a pilot. Ask that question early: it is the one line of the three your org chart cannot tell you.

One capacity pays for all three

Everything above lands on one meter: a Fabric capacity, sold as F-SKUs. (The F number is the CU total, so F2 = 2 CU, F4 = 4, on up through F64, F128, and beyond.) The capacity is the invoice. There is no separate planning bill and no license key. You buy CU; roles, overhead, and jobs draw from it; whatever planning does not use stays available to your notebooks, pipelines, and Power BI.

Capacity prices are public. At Microsoft’s US pay-as-you-go list rates:

Two notes on buying capacity. Reserved capacity bills every month whether planning runs or sleeps, at a lower rate, so a free dormant month shows up as freed headroom rather than a smaller invoice; pay-as-you-go costs more per CU and can scale down between cycles, which is where the off-season saving becomes cash. And if you already run Fabric, planning is a slice added to your existing peak, not a second capacity to buy alongside it.

The fine print that moves

Two facts to check before you plan a deployment, because both keep changing. Regions: a meaningful list of Azure regions does not support Fabric Planning yet (East US and East US 2 among them as of this writing), so check Microsoft’s live list for your region. And AI: whether Copilot draws from the same CU pool or bills separately has not been published (a polite way of saying nobody has told me yet). When Microsoft speaks, this paragraph changes.

The questions I keep getting about Fabric Planning pricing

Someone opened a plan just to look. What did that cost?

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, because entering one number turns that Viewer into a roughly $30 Stakeholder window, and touching the model opens a roughly $150 Planner window. (Microsoft’s wording, opens or meaningfully engages, leaves the bare peek slightly ambiguous; I treat any open as billable until told otherwise.)

I’m a Stakeholder at 0.23 CU (~$30/$18 PAYG/Reserved). Can I do unlimited stakeholder things?

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 overhead (Cost two): the compute underneath draws from the Fabric capacity you already own. The seat is fixed; the compute beneath it flexes. Whatever role you’re in, that one charge covers every artifact and unlimited activity across Planning Sheets, PowerTable Sheets, and the Intelligence (visual) Sheets.

Can we lower a bill by closing sessions or downgrading roles?

The window runs out either way. Cost control happens before the click.

Do users also need Power BI or Fabric per-user licenses on top of this?

The billing post prices planning roles and is silent on per-user licenses. Fabric’s standard workspace access rules still apply (below an F64, viewing Power BI content generally requires a per-user license; at F64 and above, free users can view). How that intersects with plan items is not yet documented; confirm it with Microsoft for your tenant before rollout, and I will update this answer when it is written down.

We run more than one capacity. Does the same user bill on both?

Sessions key on the user plus the capacity, so yes: one user active on two capacities opens two sessions, one on each. Confirmed by the product team.

Can a small team run this on the smallest SKU?

One Planner alone holds 58% of an F2’s two CU, the number from the top of this piece. Add a few Stakeholders and an overhead buffer and the F2 is oversubscribed. F4 is the practical floor.

Will planning starve the capacity our reports run on?

They share the pool, so size for the planning peak on top of your existing peak.

Where this leaves you

That is the model. Three roles priced by session, overhead on capacity you own, jobs billed per successful run, one F-SKU paying for all of it. What your number comes to depends on who does what in your planning cycle, and that is a sizing exercise: put your own user mix into the calculator at fabricplanning.io/calculator and it recommends an F-SKU with the mechanics above built in. Part 2 walks a real 2,200-person organization through the math in dollars. My opinion of this pricing model is a short one, and it is coming in Part 2.

The meter is readable. What it reads is your org chart.

Subscribe now

Fabric Planning is in preview until GA. Everything here reflects Microsoft’s published billing post and product documentation as of July 2026, plus direct confirmations from the product team where noted; preview terms move, so verify with Microsoft before committing budget. Per-role dollar figures are derived from Microsoft’s published US pay-as-you-go capacity list prices, which vary by region; Microsoft publishes no per-role dollar rate. Buffers and scenarios are planning assumptions, not Microsoft-published sizing. fabricplanning.io, including the calculator and the roles page, is my own companion site for this publication; everything there is free to use.

Sources: Billing for Microsoft Fabric Planning (Preview), Microsoft Fabric Updates Blog, June 2026. Introducing Planning in Microsoft Fabric IQ, Microsoft Fabric Updates Blog. Microsoft Fabric capacity pricing, Azure. Role rates per Microsoft’s preview session materials, with session mechanics confirmed directly by the product team (July 2026), tracked in the Fabric Planning Knowledge Base. fabricplanning.io/calculator and fabricplanning.io/resources/roles.

The question I get in every demo, answered plainly: who builds it, who owns it, and why the arrangement works in your favor.

I have given a lot of Fabric Planning demos this year, and the same question comes up before I am ten minutes in. Someone leans toward the camera and asks, “Wait, is this actually a Microsoft product, or is it a third-party tool dressed up to look like one?”

It is a fair question. Finance teams have been sold “native” before and found out later that native meant a custom visual writing to a database it did not really control. So let me answer it the way I answer it live.

Fabric Planning is native. Microsoft launched it as a first-party capability at FabCon Atlanta on March 18, 2026, co-engineered with Lumel. You create it inside Microsoft Fabric as a first-party item called Fabric Plan, sitting inside Fabric IQ. There is nothing to buy separately, no second vendor contract, no extra SKU, and no per-user fee bolted onto the side. It runs on the Fabric capacity you already pay for, under the same admin controls and the same security model as every other Fabric workload. You buy it from Microsoft, you run it inside Microsoft, and Microsoft supports it.

So where does it come from? This is the part worth understanding, and I have found one clean way to explain it.

Think Azure Databricks

If you have used Azure Databricks, you already understand how this works. Azure Databricks is a first-party Azure service. Microsoft sells it, Microsoft bills it on your Azure invoice, and Microsoft supports it under the same agreements as the rest of Azure. The engine inside it was built by Databricks, and the two companies engineered the Azure version together. Nobody opens an Azure Databricks workspace and calls it a third-party tool. It is an Azure service that happens to run on a great engine built by a focused partner.

Fabric Planning has the same shape. Microsoft owns the surface: the distribution, the billing, the security envelope, the support line. The planning engine was built by a company called Lumel and licensed by Microsoft for exclusive native use inside Fabric. When you turn it on, you are using a Microsoft workload. The fact that a partner built the engine tells you something about how it was made. It does not change what it is.

So who is Lumel, and why should you be glad?

This is where I tell finance leaders to relax, because the arrangement is better for you than a purely internal build would have been.

Lumel is the team behind the planning engine. They are about 400 people with more than 3,000 customers and over 15 years of building planning and reporting tools, so they did not wander in off the street. Their Power BI planning product, ValQ, won a Financial Modelling Innovation Award in 2020, and Lumel was rated Best Overall EPM Vendor in the 2025 BPM Partners study. Microsoft names them a Strategic ISV Partner for Fabric. Fabric Planning is not a fresh 1.0. It is the culmination of the products they have shipped on Power BI for years, rebuilt to run natively in Fabric.

Now think about incentives. Inside a company the size of Microsoft, an internally built feature competes for attention with everything else on the roadmap, and a great deal of that attention right now goes to AI and Copilot. Priorities shift, and features can stall when a bigger initiative shows up. Fabric Planning does not carry that risk in the same way. It has a dedicated team whose entire reason for existing is to make this one thing great, and their success is tied directly to the product getting better. That means faster iteration and far less chance of the feature going quiet because something shinier landed down the hall.

You get the better half of both worlds. The reach and support of Microsoft on the outside, and a team on the inside that lives or dies by how good the planning product is.

Why you mostly do not need to care

For most of you, the ownership question matters for about thirty seconds, and then it stops mattering. Your security team cares that it is a certified first-party workload governed by Fabric, with identity flowing from Entra ID. When someone leaves and their account is switched off, their access to the plans goes with it, and there is no separate planning login to chase down. Your procurement team cares that there is no new vendor to onboard and no new contract to sign, because the spend runs through your existing Microsoft agreement and counts toward your MACC. Your admins care that it lives under the controls they already run. On all counts, the answer is the same one you get for any other Fabric workload.

Over time the Lumel name will fade into the background the same way you never think about who built any individual piece of Fabric. You will just call it Fabric Planning, because that is what it is.

The part that was never possible before

The reason I am excited about native, beyond the clean answer to the procurement question, is what it lets you put in one place. Your Power BI semantic models, the ones your organization has invested years in, can sit right next to your planning and your variance reporting, governed by the same security and living on the same data. Analytics and planning stop being two systems you stitch together and become one place where you do the work.

Outside validation backs this up. In May 2026 the IBCS Institute, which sets the standard for how business charts and tables should look, certified Fabric Planning’s reporting. Their CEO, Jurgen Faisst, said it produces IBCS variance reports straight from planning sheets with no coding or ETL.

If you want to get your hands on something today, PowerTable, the data management layer, is the easiest place to start. The product as a whole is close to general availability, so the other pieces are in good shape too. PowerTable is just the simplest on-ramp, and it is the part people keep asking me about.

A fair caution before you run anywhere: Fabric Planning is still in preview. I would not put a live planning cycle on a preview feature yet. Try it on a Fabric trial, prove out a simple use case, and make a deliberate call when it reaches general availability. I keep the running list of what is ready and what to watch in the FAQ.

One last thing

Here is the real reason Fabric Planning PowerTable keeps coming up. Everybody has that one Excel file, the master list that three people email back and forth until nobody knows which copy is right. PowerTable is where that file goes to grow up: a no-code Fabric app with real security, approvals, and an audit trail, sitting next to your planning. If you ran Master Data Services, which Microsoft is removing in SQL Server 2025, it is also a lightweight place to land.

So a few of us built a deep dive on it. Mastering Fabric Planning PowerTable is a hands-on, two half-day workshop with five people who work in this every day. The first cohort starts Monday, June 29, the group is small, and the launch price is half off. Last call before it kicks off next week.

Enroll here →

Also if you want to stay up to date on Fabric Planning, hit the subscribe button.

Subscribe now

Planning in Microsoft Fabric IQ is about to enter general availability. Microsoft introduced it as a public preview at FabCon Atlanta in March and has said GA lands later in June, which is fast for an enterprise planning and write-back workload. (the Fabric blog announcement)

One correction I keep making, since people place it at Build: the reveal was FabCon. Build 2026 in early June is where the confusion starts, because Microsoft positioned Fabric IQ broadly as GA there and put Planning close behind, so the two get merged. (Microsoft’s phrasing for Planning is “later in June,” and no firm date is on the page as I write this.)

I have already written what Planning is and how to stand up your first item. Those links are at the bottom. The questions I get now are the practical two. What does it cost, and can I run it where my data already lives.

What it costs

There is no per-seat license. Planning runs on your Fabric capacity and consumes capacity units, the same pool that already runs your Power BI and the rest of Fabric. You do not buy anything on the side.

What trips people up is how the meter works. The first action a user takes sets their role, and that role’s capacity is billed for the next thirty days. Build or model the plan and you are a Planner. Enter or write back data and you are a Stakeholder. View only and you are a Viewer.

Each role holds a steady slice of capacity, measured in the same unit your Fabric capacity (the F-SKU) is sold in. A Planner holds 1.16 CU, a Stakeholder 0.23 CU, a Viewer 0.05 CU. That is the share of your capacity the role keeps occupied, so it lines up directly with the SKU number: one Planner is 1.16 of an F2’s 2 CU, about 58 percent of it. The roles sit about five times apart at each step, so a Viewer is close to free and most of your cost is the small group actually building.

Add the slices across everyone and that total is the capacity your plan needs. A worked example from the calculator I built: three Planners, twenty Stakeholders, and fifty Viewers come to 10.58 CU, or 12.17 with a 15 percent buffer on top. That fits an F16, about three quarters full.

Figure 1. The capacity calculator: three Planners, twenty Stakeholders, and fifty Viewers, with a 15 percent buffer, size to an F16 at about three quarters full.

Turn on dollars and pick a region. The CU each role consumes is the same everywhere; the region only changes the price of one CU. In Central US that F16 runs about $2,100 a month pay-as-you-go, or about $1,250 on a one-year reservation, roughly 41 percent less. About $1,600 of the pay-as-you-go bill is Planning’s share, the same three quarters your plan occupies on the F16, and the rest is headroom for other Fabric work. (the calculator splits the one capacity bill into those parts; they are not separate charges.)

Figure 2. The same plan in dollars (Central US): the F16 pay-as-you-go next to the one-year reservation, with the per-role breakdown.

The calculator keeps to one unit and one set of numbers, current as of June 2026. You can run your own user mix in it at fabricplanning.io/calculator. For the live dollar cost of a CU in your region, check Microsoft’s Fabric pricing page, and for a fuller estimate, Lumel, Microsoft’s development partner for Planning.

Can you run it in your region

Before you create your first Plan item, check one thing: your region.

In the preview region list, East US and East US 2 are both excluded, along with about a dozen others. The likely reason is the current scramble for AI compute: those regions are heavily backlogged, and there is no published date for when Planning reaches them. If you are in the East, treat the timeline as unknown.

If you are blocked and cannot wait, there is a workaround, though it costs you. Spin up a separate Fabric capacity in a supported region (North Central US, for example) and run the Plan there, while you keep the Fabric SQL database that holds your plan data in your source region. OneLake shortcuts bridge the two without copying the data. You manage that Plan capacity, and its cost, on its own. You pay for the path in cross-region latency and some data egress. And if residency rules keep your data in an East datacenter, get security to sign off first, because the write-back still crosses the line.

Treat the cross-region setup as a bridge. You cannot change a workspace’s region in place, so when your home region reaches GA you migrate the Plan over. The Plan item supports source control, so that move is a redeploy into the new region rather than a rebuild. And verify availability with Microsoft before you pick, because choosing a region in any tool does not confirm that Planning runs there.

Pick the region you can run in today, and schedule the move home for when Planning reaches yours.

Want to go from reading to building?

PowerTable is where I tell everyone to start with Fabric Planning. It is the lowest-risk way in, and it is the part I use most. If you want to go from reading about it to building in it, I am running a hands-on workshop on exactly that.

Mastering Fabric Planning PowerTable is a two half-day virtual workshop (June 29 and 30, 2026), taught with four other Fabric and FP&A practitioners: Nikola Ilic, Shabnam Watson, Artur König, and Miguel Félix. It is a small working cohort with direct Q&A, not a webinar (it is hands-on and assumes you are comfortable with Fabric basics). The first cohort is half off, $499 instead of $999.

Save your seat for Mastering Fabric Planning PowerTable.

Fabric Planning is my field guide to planning and budgeting going native in Microsoft Fabric, written from the FP&A side of the table. Subscribe to get the next one.

Further reading: “Fabric Planning: What, So What, and Now What?” and “Fabric Plan Step Zero.”

An independent knowledge hub for Microsoft Fabric Planning. Not affiliated with Microsoft. Published by Data Crafters, a Microsoft Fabric Featured Partner.

It walks through all seven, with extra attention where you should slow down.

Step 1: Confirm Fabric Plan is available in your region

You need to make sure your region is supported. The list is here:

· https://learn.microsoft.com/en-us/fabric/iq/plan/overview-regions

If it is supported, move to the next step. If not, here is a workaround, with a warning attached.

Fabric will let you change capacity later. It will not let you change the region of a workspace once it has Fabric items that cannot move across regions. The region you pick at workspace creation is grounded to that workspace for its lifetime. If your region is not supported, you have two trial options: a Fabric trial in a supported region, or capacity temporarily bought in one. I’d only suggest going this route if you genuinely want to test Plan. The catch: treat this purely as a trial. You’ll rebuild from scratch when you move to production.

Regions are sticky. Capacity can change. Region cannot.

Step 2: Turn on the tenant setting (and pick who can create)

From the Fabric admin portal, you have to turn the Fabric Plan setting on. Plan is in preview, and there is a tenant setting that controls who can create Plan items. I expect this control to stay even after GA, because some organizations won’t want Plan available to everyone. When you turn it on, you can also scope who can create Plan items, so you don’t have to open it to the whole tenant.

Tenant-wide enablement is the wrong default during preview, because every Plan item spins up its own infrastructure in whichever workspace it gets created. Letting any user create a Plan item anywhere is the same shape of mistake as letting any user provision an Azure SQL database without a sponsor. A reasonable group for an early pilot includes Fabric admins, the workspace admins for the workspaces hosting Plan items, the FP&A or finance solution owner, the data model owner, and whoever is participating in the workshop.

The Plan (preview) tenant setting in the Fabric Admin portal.

Step 3: Two workspaces, separate the app from the data

Technically you can skip this and create the Plan item now. From experience, do not.

Use two workspaces.

A Plan workspace and a separate data workspace.

The first is the Plan workspace. It holds the Plan item itself.

The second is the data workspace. It holds the Fabric SQL database where your writeback data lives.

The primary reason: end users should not have direct access to the application database, the same way they should not have a SQL login to the ERP database. Separate the app from the data.

You can put everything in one workspace for a demo. Do not do it in production.

Step 4: The Fabric SQL database

Inside the data workspace, create the Fabric SQL database. More on Microsoft Learn. The path is Databases, then New, then SQL database. Provide a name (something simple like Fabric SQL is fine for the first run) and select Create. To create the Fabric SQL database, you need Member or Admin role in the data workspace.

Creating the Fabric SQL database from the data workspace.

Step 5: Connection to the SQL database

Fabric Plan is an application. Like any application talking to a database, it needs a connection, even when the database lives inside Fabric.

Open Settings, then Manage connections and gateways, then New, then Cloud. Choose SQL database in Fabric as the connection type. Set authentication to OAuth 2.0. Sign in. Select Create.

A Fabric cloud connection is not a connection to a specific server. It is a connection to every Fabric SQL database the creator has access to.

Anyone you share the connection with inherits that reach. Pick the creator account deliberately.

Manage connections and gateways: a cloud connection to SQL database in Fabric, OAuth 2.0.

Step 6: Creating the Plan item

The Plan item itself is the easy part. Inside the Plan workspace, choose New item, then under Develop Data, pick Plan (preview). Name it.

New item, then under Develop data, then Plan (preview).

The Plan item creation automatically provisions the app database in the same workspace. That auto-created database stores Plan metadata. It is not the data database we created in Step 4 -- keep them separate. From this point on, everything else (PowerTable sheets, Planning sheets, Intelligence sheets) happens inside the Plan item.

Step 7: Point the Plan item to the connection

We already created the connection in Step 5. Now we point the Plan item to it.

Pointing the Plan item to the cloud connection.

Ready for Takeoff

Now you don’t have any excuses😅.

Go ahead and create your first Fabric Plan item, and break a few things on purpose. That is the fastest way to learn.

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.

[Full Webinar]

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.