Fabric Plan gives you several ways to build a plan, and choosing the right one matters more than any other design decision. This session walks through six modelling and implementation methods and when each one fits, then covers sizing, allocations, security and approvals, and ends with live Q&A.
Key takeaways
- Choose the method that fits the plan. There are six: context filtering, the measure model, Cube, Dimension Partitioning, PowerTable integration and the row model. Context filtering is the default and the most self-service. PowerTable integration and the row model need more design up front. The most common mistake is forcing every use case into context filtering.
- Many measures in your semantic model? Start with the measure model. If you've spent years building KPIs and measures in Power BI, the measure model puts them in rows in a tree view, which executives like because they can see how each KPI rolls through. The row model suits strategic and driver-based planning, but you build the business line by line, so changing a hierarchy later means rebuilding it. Start with the measure model and move to the row model if it doesn't fit.
- For several views of one plan, try Pivot before Cube. Pivot lets you set up views by region, segment or category on the same plan, and they reconcile with each other. When different teams plan at different grains, such as product, store or customer, or you're planning across many dimensions, Cube keeps all of those views in line.
- Global plans use Dimension Partitioning. Each country gets its own sheet with its own currency, grain and even planning frequency, and InfoBridge consolidates them into the group view. The trade-off is upkeep: a formula change has to be made on every sheet. For exchange rates, you can also keep the rates in a PowerTable reference table and look them up.
- Line-item planning belongs in PowerTable. Planning by employee, customer, material or SKU, or for products and customers that don't exist yet, starts in PowerTable. You define the members there and bring them into the planning sheet.
- Size the slice, not the semantic model. The semantic model can hold billions of rows, but a plan never needs all of them. Filters and row-level security mean each planner works on their own product, region or customer group, and most plans need fewer than 1 million cells. Don't try to copy the semantic model into the planning grid.
- Security builds on what you already have. Sign-in is through Microsoft Entra ID. Database and OneLake security, row- and object-level security from the semantic model, and workspace roles all carry through. On top of that, Fabric Plan adds its own roles and policies (who can see, edit, write back, create scenarios or comment), Home Layout for role-based landing pages, a full audit trail, sensitivity labels and Private Link.
FAQ
- Should a full budget (revenue, COGS, OPEX and CAPEX) live in one Plan item, or one per module? Put them in one Plan item, as separate sheets. Sheets in the same item can talk to each other, and each sheet can have its own security. Plans that need to integrate shouldn't be split across separate items.
- An approval changes the status and sends a Teams message, but doesn't lock the data. Can it? Yes. Approvals are set up with formulas in data input, and a second formula can lock a column or a set of cells once the status is Approved.
- After we publish the semantic model, the plan keeps showing old values for a while. Why? The lag should be no more than a few seconds once the semantic model refreshes. The usual cause is that the refresh never ran. If you change data in PowerTable that's attached to the semantic model, trigger a semantic model refresh before the change will show in the plan. Event triggers can run that refresh automatically after a writeback.
- Can Fabric Plan read plans from Microsoft Project? There's no live connection to Microsoft Project. Load the Project data into your data platform, build a semantic model on top of it, and Fabric Plan reads from that.
- Is Fabric Plan Microsoft software or a Lumel product? For all practical purposes it's Microsoft software. You buy it from Microsoft, Microsoft hosts and supports it, and it's part of Fabric. It's co-engineered with Lumel, which builds it.
- Was the dashboard in the demo built in Power BI? No, it was an Intelligence sheet. You can embed planning and PowerTable sheets in an Intelligence sheet next to charts and IBCS-certified visuals, so one sheet can serve as a variance dashboard or a financial report.
Resources
