Building a semantic model for Fabric Plan — how is it different from a Power BI model?

Started by Marcus Delacroix · 1 year, 6 months ago · 3 replies · 1 view

Marcus Delacroix Participant

1 year, 6 months ago

I'm a BI developer used to building Power BI semantic models for reporting. I now need to build a model that also powers Fabric Plan. What changes when the model needs to support writeback planning, not just read-only analytics?

3 Replies

Sort

Raj Subramaniam

Microsoft Fabric Consultant · CloudBridge Solutions · 1 year ago

Key differences: (1) Planning needs writeable input measures — model these as additive fact tables at the correct grain, not as calculated columns. (2) Avoid measure dependencies that would make planning inputs circular. (3) Use clean, flat hierarchies for plan dimensions — complex parent-child hierarchies can cause unexpected roll-up behaviour in Planning sheets.

Up

0

David Thornton

Director of Enterprise Analytics · Stellar Manufacturing · 1 year ago

The most important constraint: your planning grain must be explicitly modelled as a fact table. If planners enter at Account × Entity × Month, you need a planning fact table at that grain. Trying to drive planning from a more granular transactional table is a path to pain.

Up

0

Omar Hassan

Data Engineering Lead · InfraCore MENA · 1 year ago

Test your semantic model queries from the Fabric Plan connection before you build Planning sheets. Send a simple SUMMARIZECOLUMNS() against your planning dimensions and verify the output matches your expectations.

Up

0