Fabric Plan · step by step
0% done What Parts Setup 1 2 3 4 5 6 7 8 Jargon Fixes

Tool-belt series · Microsoft Fabric · Plan (Fabric IQ)

Fabric Plan, explained
like nobody explained it to you.

Every step, in order, in plain English — what you click, what it actually does, and why it exists. No assumed knowledge. If you've felt scattered every time you opened Plan, that's because the docs describe forty features and never tell you the four that come first. This does.

The whole product, in one sentence

Plan is a spreadsheet that's plugged in at both ends — it reads real numbers out of your Power BI model, lets people type new numbers on top, and saves those into a real database.

That's it. Everything else on this page is detail hanging off that sentence. When you get lost later, come back and re-read it — nine times out of ten your confusion is "which end am I on right now, the reading end or the writing end?"

Semantic model your existing Power BI model actuals, dimensions, measures Plan only READS this READ Planning sheet the grid people actually use rows = what · columns = when humans type numbers in here WRITE Fabric SQL database a real table, in your workspace budgets, forecasts, scenarios this is called WRITEBACK plan vs actual, in one report the loop closes — your budget becomes data, next to the actuals it will be judged against
reading endthe bit you buildwriting end

How to use this page

Read it top to bottom, once, without touching Fabric. Then go again with Fabric open in another window and do each step for real. Every step has the same four parts: in plain English (what this thing is), do this (the literal clicks), how you know it worked, and when it goes wrong.

Tick boxes as you go — progress saves in this browser, on this device. Sections 1–8 are in strict order and each one genuinely needs the one before it. Skipping is the thing that makes Plan feel chaotic.

Somewhere in your organisation there is a budget spreadsheet. Someone exports actuals from Power BI into it, a dozen people type next year's numbers into it, it gets emailed around, versions multiply, and eventually a hero re-keys the final numbers into something official. Plan is Microsoft deleting that spreadsheet and putting the same job inside Fabric, where the actuals already live.

In plain English

Microsoft calls Plan an "EPM & CPM solution". Ignore the acronyms. Enterprise / Corporate Performance Management just means budgeting, forecasting and target-setting — the numbers about the future, as opposed to reporting, which is numbers about the past.

Power BI has always been a read-only tool. You could look at last quarter, but you could not type next quarter into it. Plan is the write-enabled half that was always missing.

Why this is a bigger deal than it sounds

The old wayWhat went wrongWhat Plan does instead
Export actuals to Excel, budget in ExcelThe moment you export, your numbers stop matching the report. Nobody can tell which file is current.The sheet reads the model live. Same measures, same definitions, no export.
A separate planning tool (Anaplan, Pigment, TM1…)Second platform, second licence, second security model, and a data pipeline between them that breaks.Same workspace, same permissions, same capacity as the rest of Fabric.
Power Apps + Dataverse for write-backYou're now a software team. Someone has to own an app forever.No-code grid. A finance person builds it themselves.
The sentence to say out loud at work"We can budget on top of the actuals, in the same place the actuals live, and the budget comes back out as data." That's the entire business case, and it lands with both finance and IT.

Where Plan sits in Fabric

Plan is an item in the Fabric IQ workload — Microsoft's grouping for the "shared business meaning" layer, alongside semantic models, ontology, graph and data agents. You don't need to understand Fabric IQ to use Plan. All you need from that sentence is: Plan is designed to sit on top of a semantic model, not on top of raw tables. That single fact explains almost every prerequisite in the next section.

Say this back to yourselfIf you cannot answer "which semantic model is this plan reading from?" you are not ready to create anything yet. That model is the foundation, and Plan gives you no way to plan without one.

Tick when true

Open the Plan docs and you're immediately hit with Planning sheets, PowerTable, Intelligence and Infobridge, all presented as equals. They are not equals. One of them is the product; the other three are things you'll want in month three. Here is the honest ranking.

PartWhat it really isDo you need it now?
Planning sheetThe budgeting grid. Rows and columns of numbers, some read from your model, some typed by humans, some calculated. This is Plan.Yes. This whole page is about this one.
PowerTable sheetA data-entry table over a database table — more like a managed list or a form than a budget. For maintaining reference data at scale.No. Later, when you need to maintain data rather than plan it.
Intelligence sheetReporting and variance analysis inside Plan — plan vs actual, charts, financial-report layouts.No. You can just use a Power BI report at first.
InfobridgeThe data-plumbing layer: pull from several sources, merge, append, pivot, group, and map data between sheets.No. Only when one semantic model stops being enough.
Why this matters so much

Every one of those four has its own toolbar, its own menus and its own docs section. If you wander between them while learning, nothing accumulates — you learn a quarter of four tools instead of all of one.

So here is the rule for the next two weeks: if the docs page you're reading doesn't say "planning sheet", close it.

Your scope, written downOne Plan item. One planning sheet. One semantic model. One budget you actually care about. Everything on the rest of this page fits inside that sentence, and you can finish it in an afternoon once setup is done.

Tick when true

Do not skip this to "just have a look". Plan fails quietly — empty dropdowns, greyed-out buttons, a sheet that loads with no data — and every one of those symptoms traces back to something in this list. Ten minutes here saves days of confusion.

In plain English

Plan doesn't read your semantic model the polite way a report does. It talks to it through the XMLA endpoint — the "back door" into a model that external tools use — and it renders itself using embed tokens, the same machinery that puts a Power BI report inside someone else's website.

Both of those are switched off in a lot of tenants and both need real capacity. That's why the requirements look heavier than "it's just a spreadsheet".

A. Tenant settings — someone with Fabric admin has to do these

Admin portal → Tenant settings. Three switches:

  • Under Integration settings: turn on Allow XMLA endpoints and Analyze in Excel with on-premises semantic models. Without this, Plan cannot read your model at all.
  • Under Developer settings: turn on Embed content in apps. Without this, the sheet itself won't render.
  • Under Developer settings, only if you'll use a service principal later: Service principals can call Fabric public APIs. Skip for now if you're signing in as yourself.

B. Capacity — what you're running on

  • The semantic model must live on an F SKU (Fabric capacity) or a Power BI Premium P1–P5.
  • Power BI Pro and PPU do not work for the XMLA + embed-token scenarios Plan needs. This is a hard stop, not a slow-down. If you're on Pro, you cannot do this at your desk today.
  • In the admin portal under Capacity settings, the XMLA Endpoint must be set to Read Only or Read Write. If it says "Off", nothing works.
  • Very small SKUs can still trip over XMLA and memory limits even when everything is switched on.

C. Permissions — the one people get wrong

  • You need Admin or Build permission on the semantic model itself.
  • Whoever creates the connection in Step 1 must be a workspace Member or Admin.
  • Contributor is not enough. A Contributor can't create or share cloud connections, and can't create Plan items that need an embed token. If you're a Contributor you will hit a wall and the error won't tell you this.
Four hard stops, checked now, not later1. A model in My workspace is not supported — move it to a real workspace. 2. Tenants or workspaces using private links can't have Plan items at all. 3. Entra B2B guest accounts are not supported — if you're a guest in this tenant, stop here. 4. Only OAuth and service principal authentication are supported for the connection.
Two things you must never do laterDon't rename the semantic model once a plan is connected to it — it breaks the connection. Don't rename the workspace that holds a Plan item — the item stops opening entirely. Decide your names before you build, because these aren't recoverable by renaming back cleanly.

Do this now

Almost everyone's first attempt goes: create the Plan, create the sheet, click Add to attach data… and the dropdown is empty. Nothing is broken. The connection simply doesn't exist yet, because you have to build it somewhere else first, before you create a plan at all.

In plain English

A connection is a saved, named, reusable "here is how to reach that model, and here is who to sign in as". It lives at the tenant level in Manage connections and gateways — the same place gateways and data source credentials live — not inside your plan.

Why separate? Because a budget gets used by twenty people who don't individually have back-door access to the model. You create one connection, you share it, and everyone borrows it. That's also why you must be a workspace Member or Admin to make one: you're handing out access.

Do this — create the connection

Fabric toolbar → Settings (gear) → Manage connections and gateways → New
  • Choose Cloud (not on-premises).
  • Give it a connection name you'll recognise in a list of forty. Something like Plan — FY27 Sales Model.
  • Connection type must be Power BI Semantic Model. This is the one that matters — the plan's dropdown filters to this type and nothing else.
  • Authentication method: choose OAuth 2.0, select Edit credentials, and sign in as yourself. (Service principal is the grown-up option for CI/CD — ignore it for your first build.)
  • Select Create.

Do this — share it with the humans who'll use the plan

next to the connection name → … → Manage users → search person → set access → Share

Access levels are User, User with resharing, and Owner. For a colleague who just needs to type budget numbers, User is right. You can do this later, but doing it now saves a confused Teams message on launch day.

How you know it workedThe connection appears in the Manage connections and gateways list with type Power BI Semantic Model. That's the whole test. In Step 3 it will show up in the plan's dropdown — if it doesn't, it's this step that's wrong, not that one.
Direct Lake models need extra workImport models just work. Direct Lake and DirectQuery are supported with limitations: they need fixed credentials, and single sign-on is not supported. For a Direct Lake model you must also go to the model itself — … → Settings → Gateway and cloud connections — and swap it off the default SSO connection onto a new one you create there, then Apply. If your first-ever plan can sit on an Import model, do that and save yourself the detour.

Tick as you go

This is the easy one. Two clicks and a name.

your workspace → New item → Plan → type a name → Create
The surprise, explained before it surprises you

A moment after you create the Plan, a Fabric SQL database appears in your workspace that you did not ask for. Do not delete it. Do not rename it. Do not "tidy it up".

That database stores your plan's metadata — the definition of your sheets, rows, formulas and layout. It is part of the Plan item, in the same way a semantic model quietly sits behind a report.

Note what it is not: it is not where your budget numbers get written. That's a different database you'll choose yourself in Step 8. Two databases, two jobs. Mixing these up is a classic week-two confusion.

Think of the Plan item as a workbookAn Excel workbook holds many sheets; a Plan item holds many sheets too — up to 25, and up to 50 visuals. So the unit you create here is "the whole budgeting workbook for this topic", not "one budget grid". Name it accordingly: FY27 Sales Plan, not Sheet1.

Tick as you go

Open the new Plan item. It offers to get data from a semantic model or from Excel, and to build a sheet from it — or to start with an empty sheet and connect it afterwards. Take the empty sheet. Doing the two things separately makes it much clearer which half is which, and that clarity is the whole point right now.

in the Plan item → Planning → name the sheet → Create then, in the new sheet → Add → Select a Connection → pick your connection → choose the semantic model → Add
In plain English

You just did two separate things that feel like one. First you made an empty grid. Then you told that grid where its numbers come from.

The grid is yours — your layout, your rows, your formulas. The model is not yours; it's shared, governed, and read-only from here. Plan never writes back into your semantic model. Keeping that boundary clear in your head is most of the battle.

"The dropdown is empty"Only connections of type Power BI Semantic Model that you personally have access to appear here. An empty list means one of exactly three things: you never made the connection (Step 1), you made it with the wrong connection type, or somebody else made it and never shared it with you. It is never a bug. Go back to Step 1.
How you know it workedYou can add fields from the semantic model into the sheet and real numbers appear. If fields appear but the cells are blank, that's usually the XMLA endpoint or capacity from Step 0, not this step.
Optional but do it early: the collaboration databaseIf more than one person will use this sheet, add a database connection for the Plan item so it has somewhere to store comments and collaboration details. It's optional and easy to add later — but "later" usually means "the day people start asking why their comments vanished".

Tick as you go

Now you shape the grid. This is the part that decides whether your plan is pleasant or painful for the next six months, and it takes about five minutes to get right.

In plain English

A planning sheet is a pivot table you're allowed to type into. Exactly like a pivot table, it has two jobs to fill:

Row dimensionswhat you're planning. Product, department, cost centre, account, region. These stack into a hierarchy you can expand and collapse: Category → Sub-category → Product.

Column dimensions — almost always when. Months, quarters, years. Sometimes also which version: Actual, Budget, Forecast.

COLUMN DIMENSIONS — usually time JanFeb MarQ1 FY total ROW DIMENSIONS what you're planning Beverages Water Juices Mocktails Gross margin read from the model — you cannot type here DATA INPUT ROW — a human types the budget here DATA INPUT ROW DATA INPUT ROW — added by you, not in the model FORMULA ROW — = Revenue - Cost every planning sheet is these three row types, arranged over a time axis

the anatomy of every planning sheet you will ever build

Start smaller than feels sensibleThree or four row levels and twelve months. Not every product, not every cost centre. You are learning a tool, not shipping the corporate budget — and a small sheet makes every later step (formulas, scenarios, writeback) fast to test instead of a two-minute wait each time.
You need at least one dimensionWriteback in Step 8 flatly requires the sheet to have at least one row or column dimension. A sheet with numbers but no dimensions has nothing to key the saved rows on, so it can't be written anywhere.

Tick as you go

Everything so far has been reading. Now you add a row that isn't in the semantic model at all and type into it. This is the point of the entire product, and it's worth pausing on when it works.

In plain English

A data input row is an empty row you bolt onto the grid so a human can type. Nothing feeds it. It exists because the model doesn't have the thing you need.

Two examples that make it click: your P&L model has revenue and expenses but no shares outstanding, so you can't compute EPS. Or you launched a product last week that has no history, so it appears nowhere in the model — but it definitely needs a budget.

The model can't answer those. A person can. That's a data input row.

Do this — two ways, same result

select a row → Planning → Insert Row → Data Input → Number or: hover a row → row gripper → Insert → Data Input

The row gripper is the little handle that appears when you hover over a row — the same idea as the drag handle on an Excel row. Using the gripper opens a side pane of row properties, which is where the useful settings live. Insert Row is greyed out if no row is selected — that's the most common "the button doesn't work" moment, and it isn't a bug.

The properties that actually matter

SettingWhat it means, plainlyWhat to pick first time
Row typeNumber (a human types) or Formula (it calculates). You can switch a row between the two whenever you like.Number.
Insert AsSingle Row adds one row here. Templated adds the same row at every level of the hierarchy — add "New product line" once, get it under every region.Single Row. Templated is the power move once you trust it.
Scaling factorWhether typing "5" means 5, 5 thousand, or 5 million. Defaults to Auto.Set it explicitly if people will type in thousands. Ambiguity here causes real errors.
Include in totalDoes this row roll up into its parent? On by default.Leave on — unless it's a memo line like headcount that shouldn't be added to money.
Distribute parent value to childrenType a number at the parent level and it spreads down to the children automatically.Brilliant for top-down budgeting. Try it once and you'll see why.
Default valueWhat the row starts as: a Static number, or copied from another Row (e.g. "start at last year's actuals").Sourcing from last year's row is the single biggest time-saver here.
Allow InputEdit mode = only editors can type. Read mode = viewers can type too.Read mode is what you want when twenty people submit budgets without editing the sheet's design.
Bind for cross filter/RLS — the security oneIf your row references another row, turn this on. Without it, row-level security leaks: a manager who should only see Canada can see a manually inserted row that quietly references US data. RLS on the semantic model does not automatically cover rows you invented inside the sheet. This is the setting that stops a genuinely embarrassing incident.
Adding a lot of rows at onceUse Insert Row(s) from the same menu: it pre-fills the parent levels, lets you add 1, 5 or 10 at a time, and can define a whole new hierarchy branch by overwriting the pre-filled parents. If you're pasting a list of new cost centres, this is the door. Bulk data input caps at 1 million rows from an Excel or CSV upload.

Tick as you go

You have actuals from the model and budget numbers typed by humans. Now you want Gross margin, Variance, Growth % — rows that are computed from other rows. That's a formula row.

In plain English — and the one mental shift

The formula engine is Excel-like: logical and mathematical functions, autocomplete, syntax help, multi-line editing. If you can write an Excel formula you can write these.

The shift: in Excel you reference cells (=B4-B7). Here you reference rows (= Revenue - Cost of sales), and the formula applies across every column automatically. You write it once and it computes for all twelve months. Once that lands, formula rows stop feeling strange.

Do this

select the row below where you want it → Planning → Insert Row → Formula
  • The new row is inserted above the row you selected. (Data input rows go below. Yes, that's inconsistent. Now you know.)
  • In the Calculated Row pane, give it a title and write the formula.
  • To reference a row: click it directly in the report while your cursor is in the formula box, or use the References tab to search the hierarchy. Typing row names by hand is the slow, typo-prone way.
  • Create only lights up once the formula is valid. A greyed-out Create button means your formula is wrong, not that the app is stuck.
Tools that make this painlessTurn on the Suggestions toggle for IntelliSense-style autocomplete. Use the Functions tab to browse what exists rather than guessing. And when a formula misbehaves, hit expand for the Maximized Formula View — line numbers and proper error messages instead of squinting at a one-line box.
Evaluated Formula For — the setting that explains weird totalsWhen a formula row crosses a formula column, something has to win. That's what this controls: All Data Source and Input Columns, All Columns, or Custom (include/exclude specific columns). If one column in your margin row shows a number that makes no sense, this setting is almost always why. It's not a rendering glitch.

Tick as you go

In Excel, "what if?" means Save As — Budget v4 PESSIMISTIC FINAL.xlsx, and then nobody can tell which file is real. Scenarios are the fix: alternative versions that live inside the sheet and cannot damage the plan underneath.

The mental model — get this and scenarios are easy

Base is your committed plan. It's the reference point everything is measured against.

A scenario is a transparent sheet laid over Base. You scribble on the overlay; Base is untouched underneath. Delete the overlay and nothing is lost.

Two rules people get wrong: every scenario sits on Base, never on another scenario — "Best case" and "Cost cuts" are siblings, not a stack. And simulations never alter Base or the source data, so you genuinely cannot break anything in here.

Base the committed plan — the thing everything is compared against Scenario: Best case sales +10% — an overlay, not an edit Scenario: Cost cuts opex −8% — independent of the other one both sit on Base never stacked on each other Copy to base scenarios are overlays — scribble freely, Base is safe underneath

why you cannot break anything with a scenario

Do this

Model → Scenario → name it → select the series to simulate → Create

"Series" just means which measures this scenario is allowed to move. Pick Sales, and the scenario can flex sales; everything else stays put. Then drag the slider on a cell, or type a value directly. Dependent measures recalculate live — change a leaf value and every parent total and calculated measure above it updates instantly. Hit Save. Add more scenarios with the + at the bottom.

The four buttons worth knowing on day one

ButtonWhat it doesWhy you'll want it
Compare ScenarioSide-by-side of two scenarios with a Δ column showing the difference.This is what you actually present. Pick Compare, With, and which measures.
Show varianceShows the gap between scenario and Base inline. Slider settings controls the colours — Increase is good is on by default (up = green).Turn Increase is good off for cost rows, or your savings will glow red.
DistributionSpread one value across many cells: copy to all rows, copy until the last column, or copy with trend so it follows the existing shape.Beats typing twelve months by hand. Reset value undoes it.
Bulk EditPick a measure, pick row and column dimensions, set a value or a percentage, Apply."Cut all European marketing by 8%" in one action.
Copy to base — the moment a scenario becomes the planWhen leadership picks a scenario, Copy to base pushes those values down into Base. Review the columns, select Proceed. Note carefully: only simulated values are copied — native measures are not. Your scenario becomes the plan; it doesn't overwrite what came from the model.
"Why can't I simulate this measure?"You can't directly simulate a calculated measure that references native measures, because it holds no value of its own — it's derived. Simulate the underlying native measures instead, and watch the calculated one move on its own. This is the most common scenario-related "is it broken?" and the answer is no.
Two more you'll reach forLock Scenario (Scenario → Settings) freezes it so nobody edits the version that went to the board. Security → Scenario controls who can even see each one — useful when "Restructuring case" shouldn't be visible to everyone.

Tick as you go

Until now your budget lives inside the Plan item. Useful, but sealed off. Writeback copies those numbers into a real Fabric SQL database table — where a pipeline can read them, a semantic model can model them, and a Power BI report can put budget next to actuals.

In plain English

Writeback is Save As, into a database table. You choose the database and the table name, and Plan creates and fills the table for you. No DBA, no schema designed in advance — it builds the structure at runtime from your sheet.

Remember Step 2: this is a different database from the one Fabric auto-created for the Plan's metadata. That one holds the definition of your sheet. This one holds your numbers.

Do this — create the destination

Writeback → Add Destination
  • Pick a database connection.
  • Pick the target database — you browse and select it from the OneLake catalog.
  • Type a Table Name. This table doesn't have to exist; Plan creates it.
  • Decimal Precision — digits after the decimal point for number columns.
  • Text Length — max length for text columns (e.g. 512 for all of them), or Custom.
  • Add.

Choose the shape: Long vs Wide

Writeback → Settings → Writeback Type
TypeWhat the table looks likePick this when
LongOne row per measure per combination — key-value pairs. Tall and narrow. Columns like Measure, Value.Default choice. Add a new measure later and the table shape doesn't change — it just gets more rows.
WideOne column per measure. Short and fat. Looks like the sheet.You want to eyeball it in SQL, or a downstream tool expects fixed columns.
Long with ChangesLong, but only the values that changed.Big sheets, frequent saves, or you want an audit trail of edits.
Wide with ChangesWide, only changed values.Same reason, wide shape.

The other Settings tabs: Data (which measures and dimensions take part), Destinations (where it goes), Advanced (system-level behaviour), General (the core options).

Do it, then check it

Writeback → Writeback → wait for the confirmation → open the database and look at the table

Actually open the destination database and look at the rows. Don't trust the toast message — look at the data. Writeback → Logs shows every run with milestones, payload size and duration; click a writeback ID for the detail. When someone asks "did the budget save?", that log is your answer.

The gotcha that will bite you, guaranteedOnce you've written back, adding or removing row/column dimensions changes the table's required structure. Plan won't silently reshape a table that already exists — you get a structure-mismatch error. The fix: drop and re-create the destination table before the next writeback. So get your dimensions settled before you point anything downstream at that table.
The ceilingWriteback handles up to 1.2 million cells per operation. Past that it isn't supported and will fail. If you're near it, split across sheets — the same 1.2M ceiling applies to each Infobridge query, and five sheets gets you to roughly 5 million cells in one workbook.
Scenarios write back tooFrom the Scenario tab: Writeback saves the selected scenario, Writeback All saves all of them. This is how "best case vs worst case" ends up as data in a report rather than a screenshot in a deck. The Writeback option only lights up after a destination exists.

Tick as you go

Jargon decoder

Every word that made a docs page feel harder than it is, translated into something you'd actually say to a colleague. Bookmark this bit — it's the part you'll come back to.

The words in the product

They sayThey mean
Plan (the item)The workbook. Holds up to 25 sheets.
Planning sheetOne budget grid. A pivot table you can type into.
Row dimensionWhat you're planning, down the left. Product, department, account.
Column dimensionNearly always time, across the top. Months, quarters, years.
SeriesA measure that a scenario is allowed to move.
Native measureA number that comes from the semantic model. Real, stored, simulatable.
Calculated measureA number derived from other numbers. Holds no value of its own, so it can't be simulated directly.
Data input rowAn empty row a human types into. The whole point of Plan.
Formula rowA row that calculates from other rows. Excel formulas, row references.
Templated rowThe same row repeated at every level of the hierarchy.
Row gripperThe little handle on hover. Right-click equivalent for rows.
BaseThe committed plan. The reference point.
ScenarioA what-if overlay on Base. Can't damage Base.
Copy to basePromote a scenario's simulated values into the real plan.
WritebackSave the numbers into a real SQL table.
Long / WideTall key-value table / one column per measure.
InfobridgeThe plumbing: merge, append, pivot, group across sources. Ignore at first.
PowerTableData-entry table over a database table. Not a budget grid.
Intelligence sheetReporting and variance analysis inside Plan.

The words around the product

They sayThey mean
EPM / CPMBudgeting and forecasting. Numbers about the future.
Fabric IQMicrosoft's grouping for the "shared business meaning" layer — semantic models, ontology, graph, agents, and Plan.
XMLA endpointThe back door into a semantic model that external tools use. Plan needs it open.
Embed tokenThe mechanism that renders Power BI content inside another app. Plan renders itself this way.
Semantic modelYour Power BI model — tables, relationships, measures. Plan reads it and never writes to it.
Shareable cloud connectionA saved "how to reach that model and who to sign in as", created once and shared.
DMTS connectionThe internal name for that connection. You'll only meet it in an error message.
RLSRow-level security — who is allowed to see which rows.
Direct LakeA semantic model reading Delta files straight from OneLake. Works with Plan, but needs extra connection setup.

When it breaks — symptom to cause

Plan's failures are quiet: empty lists, greyed buttons, blank cells. Almost none of them are bugs. Find your symptom on the left.

What you seeWhat's actually wrongFix
Connection dropdown is empty when adding dataNo connection of type Power BI Semantic Model exists, or it wasn't shared with youStep 1. Check the connection type is exactly right, and that it's shared to your account.
Sheet loads but every cell is blankXMLA endpoint off, or capacity doesn't support itStep 0 — tenant setting and capacity XMLA setting must both be on.
Can't create the Plan item at allYou're a Contributor; embed-token items need Member or AdminGet your workspace role raised. Contributor also can't create or share connections.
Everything is greyed out and you're on Power BI ProPro and PPU aren't supported for XMLA + embed-token scenariosYou need an F SKU or P1–P5. No workaround.
Insert Row is greyed outNo row is selectedClick a row first. That's genuinely all it is.
Create stays greyed in the formula paneThe formula isn't valid yetOpen the Maximized Formula View for the real error message.
A plan that worked yesterday won't openSomeone renamed the workspaceDon't rename workspaces containing Plan items. Ever.
Plan lost its data sourceSomeone renamed the semantic modelSame rule. Renaming breaks the connection.
Writeback fails with a structure mismatchYou changed dimensions after the table was createdDrop and re-create the destination table, then write back again.
Writeback fails on a big sheetOver 1.2 million cells in one operationSplit across sheets. The cap is per operation.
"DMTS connection is deleted or not found" on a PowerTable sheetThe connection was deleted; the recovery screen doesn't appearCreate a new PowerTable sheet using Existing Table and configure the same table again.
Users see rows they shouldn'tRLS gaps: PowerTable queries run as the connection's identity, not the user's; Blend (From Sheets) doesn't apply RLS at allDon't rely on database-level RLS through these paths. And set Bind for cross filter/RLS on inserted rows.
Can't insert a data input columnThe semantic model contains unsupported Unicode charactersClean the offending names in the model.
Nothing works and you're a guest in this tenantEntra B2B accounts aren't supportedUse an account native to the tenant.
Plan items unavailable across the whole tenantThe tenant or workspace uses private linksNot supported. This one is architectural, not a setting.

Ceilings worth memorising

LimitNumber
Sheets per Plan item25
Visuals per Plan item50
Cells per writeback operation1.2 million
Cells per Infobridge query1.2 million (~5 million across five sheets)
Rows per bulk data input from Excel/CSV1 million

Now build the small one

Reading this page teaches you the vocabulary. Building one tiny plan end to end is what makes it stick — and the small version takes an afternoon, not a quarter. Pick something you genuinely care about but nobody depends on yet: next year's travel budget, headcount for one team, revenue for one product line.

The afternoon project

When you've done all sevenYou've used every concept that matters in Plan. Everything left — approval workflows, Intelligence sheets, Infobridge, PowerTable, allocation rules — is an addition to this skeleton, not a new thing to learn from scratch. That's the point at which Plan stops feeling like forty features and starts feeling like one tool.
← back to the tool belt