How to Create a Cube in Microsoft Fabric IQ - A Practical Walkthrough

There is a moment in most planning projects where someone asks the question that decides how the next two years go. It sounds innocent. "How should we structure this?" And the honest answer is that if you get the cube wrong at the start, you will feel it every single quarter afterwards, in slow refreshes, in numbers that do not tie out, in the one analyst who becomes the only person who understands why the model behaves the way it does. So before we talk about clicking buttons, I want to be clear that creating a cube in Fabric IQ is less a technical task and more a modelling decision that happens to have some technical steps attached.

I have watched finance teams treat cube creation like setting up a spreadsheet. Just start typing and sort it out later. It does not work like that. A cube is the shape of your planning world, the dimensions along which you slice numbers and the measures you slice. Get the shape right and everything downstream feels obvious. Get it wrong and you spend the next year bolting on workarounds.

Microsoft's own reference for this is the create a cube guide, and it is worth reading as the source of truth for the current interface. What follows is the practical version, the bits we talk through with clients before anyone touches the screen.

What a cube actually is, in plain terms

Skip the theory for a second. A cube in Fabric IQ is a container for planning data organised by dimensions. A dimension is a way you want to look at the numbers. Time is almost always one. So are things like cost centre, product line, region, scenario, and account. Where two or more of those intersect, you get a cell, and that cell holds a value. Budgeted revenue for the Brisbane branch, product category "services", month of March, scenario "budget". That single number lives at the intersection of four dimensions.

The reason this matters is that planning is inherently multidimensional and spreadsheets are not. A spreadsheet has rows and columns and then people fake the third dimension with tabs, and the fourth with separate files, and by the time you are on your ninth version emailed around the finance team, nobody can tell you which one is the truth. A cube holds all of those dimensions in one structure, so there is one place a number lives, and everyone is looking at the same one.

If your team has lived through the "which version is current" nightmare, that alone is the pitch for cubes. We covered the broader why in an earlier piece on what Fabric IQ planning cubes mean for your budgeting process, but here we are getting our hands dirty.

Before you create anything, decide your dimensions

This is the part people rush, and it is the part that matters most. Do not open Fabric IQ first. Open a whiteboard, or a document, or the back of an envelope, and answer one question. What are the ways this business needs to slice its plan?

Some of these are obvious. You will have time. You will almost certainly have some version of an organisational structure, cost centres or departments or legal entities. You will have accounts, the chart of accounts your finance system already uses. Then it gets business specific. A retailer plans by store and product category. A professional services firm plans by practice and by client segment. A manufacturer plans by product line and by plant.

The trap is going too granular too early. I have seen a team insist on planning at SKU level across every store because "we might need it". They ended up with a cube so large and so sparse that nobody filled most of it in, refreshes crawled, and within six months they quietly re-planned at category level, which is where they should have started. Plan at the level of decisions, not the level of your transactional data. You forecast by product category because that is the level at which someone actually makes a call. The SKU detail lives in your reporting, not your plan.

A rough rule we use with clients: if a dimension member will never have a human make a deliberate planning decision about it, it probably does not belong as a planning dimension. It belongs in the detail you report against later.

The actual creation steps

Once your dimensions are settled, the mechanics in Fabric IQ are reasonably straightforward. You create the cube inside your planning workspace, give it a sensible name (please, not "Cube1" or "Budget_final_v2"), and start defining its dimensions. For each dimension you are telling Fabric IQ what the members are, whether that comes from an existing semantic model, a table you connect, or a hierarchy you define.

The connection to existing data is where Fabric IQ earns some of its keep. Rather than hand-typing every cost centre, you point a dimension at a source that already holds them, so when the business adds a new branch, it flows through rather than becoming a manual edit. Set this up properly at the start. The teams that hard-code dimension members are the teams that spend the following year in maintenance.

You will define hierarchies within dimensions too. Time rolls up from month to quarter to year. Cost centres roll up to departments to divisions. These rollups are not decoration. They are how the cube aggregates, so that when someone enters a number at the branch level, the division total updates without anyone recalculating anything. Getting hierarchies right is what makes the cube feel alive rather than like a static grid.

Then you define measures, the actual numbers, and how they behave. Most planning measures aggregate by summing across dimensions, but not all. A headcount measure at year level is not the sum of twelve monthly headcounts, it is the closing or average figure. Fabric IQ lets you control this aggregation behaviour, and this is exactly the kind of detail that, if you skip it, produces a plan where the annual totals are quietly nonsense and someone catches it three weeks before board reporting.

Where it is genuinely good, and where it still bites

Honest assessment time. The cube concept in Fabric IQ is the right idea, and having it sit inside the same platform as your reporting and your data engineering is a real advantage. For years, Australian businesses ran planning in one tool, reporting in Power BI, and data prep in something else, with brittle exports gluing it together. Bringing planning into Fabric closes that gap, and the write-back capability means numbers entered in the plan can flow to where they need to go rather than living in an island.

But it is newer than the marketing implies, and you will feel the edges. The interface for building larger, more complex cubes still has moments where you wish for the maturity of tools that have been doing this for twenty years. Performance on very large, sparse cubes is something to test with your real data volumes before you commit, not something to assume. And the ecosystem of people who genuinely know this tool well is small right now, because it is new, which means finding help is harder than for, say, Power BI. That will change, but it is the reality in 2026.

The other thing to watch is the temptation to over-engineer. Because the tool can do a lot, teams build cubes with fifteen dimensions and elaborate driver logic, and then discover that nobody in finance can maintain it. The best cubes we help build are almost boring in their simplicity. Enough dimensions to reflect how the business actually plans, and no more.

Getting it right the first time

If I had to compress everything into advice, it would be this. Spend more time on the dimension design than you think you need to, connect dimensions to live sources rather than hard-coding them, plan at the level of decisions rather than the level of your raw data, and check your measure aggregation behaviour before you trust a single total. A cube that is well shaped feels effortless to use. A cube that is badly shaped feels like fighting the tool every day, and no amount of clever formulas fixes a bad foundation.

This is also where having someone who has built these before genuinely pays for itself, because the expensive mistakes all happen in the first fortnight, before anyone has entered real numbers. Our Microsoft Fabric consulting work is often exactly this, sitting with a finance and data team to get the model shape right before it hardens into something painful to change. And if you are earlier than that, still weighing up whether Fabric IQ planning is the right home for your budgeting at all, that is a strategy conversation more than a technical one, and our AI and data strategy work is where that starts.

Fabric IQ cubes are a solid piece of a genuinely useful platform. Treat the creation step as the modelling decision it really is, not a bit of setup to rush through, and you will get a planning structure that serves the business rather than one it has to work around. If you want a hand shaping your first one, get in touch and we will talk through your dimensions before you build anything.