4.4 Advanced Model Features
Key Takeaways
- Calculation groups apply reusable calculation logic (time intelligence, currency, formatting) to many measures without duplicating measures.
- Field parameters let report users switch which dimension or measure a visual displays from a slicer, without bookmarks.
- Composite models combine multiple storage modes and sources in one model, with table-level storage mode and dual mode for shared dimensions.
- The large semantic model storage format enables models to grow beyond the default size limit and is required for very large Import/Direct Lake models.
- Calculation groups and field parameters solve different problems: calculation logic reuse vs user-driven field selection.
Beyond Basic Modeling
The exam expects familiarity with the modeling features that scale a semantic model to enterprise use. These appear in scenario questions where a straightforward measure or relationship is not enough.
Calculation Groups
A calculation group packages reusable calculation logic into calculation items that can be applied across many measures. The classic use is time intelligence: instead of authoring Sales YTD, Sales PY, Sales YoY% for every base measure, you create one calculation group with YTD, PY, YoY% items that work against whichever measure is in the visual. Calculation items can also drive dynamic format strings. They reduce measure sprawl dramatically and are a frequent 'best solution' answer when the scenario says 'the same time-intelligence variants for dozens of measures.'
Field Parameters
A field parameter lets report consumers choose, from a slicer, which field or measure a visual uses. For example, a single chart that the user can flip between Revenue, Units, and Margin, or between Product, Region, and Channel on the axis. It is a modeling feature (a generated table of fields) and replaces clunky bookmark-based field switching. Distinguish it from a calculation group: field parameters switch which field/measure is shown; calculation groups change how a measure is calculated.
Composite Models and Dual Mode
A composite model mixes storage modes and sources in a single semantic model — for example a huge fact table in DirectQuery or Direct Lake alongside small Import dimensions, or two different DirectQuery sources. To avoid forcing every cross-source query to the slow path, shared dimension tables can be set to Dual storage mode: the engine uses them as Import when possible and as DirectQuery when the query requires it. Composite models also enable connecting to an existing published semantic model and extending it locally.
Large Semantic Model Storage Format
Semantic models have a default in-memory size limit per capacity. Enabling the large semantic model storage format removes the default cap (subject to capacity limits) and is required for very large Import models and for big Direct Lake models. On the exam, the cue is a model that fails to refresh or load because it exceeds the default size — the fix is enabling large semantic model format on a capacity that supports it, not switching the whole model to DirectQuery by reflex.
An analytics team maintains 40 base measures and is asked to add YTD, prior-year, and year-over-year variants for all of them. They want to avoid creating 160 measures. What is the best approach?
A large fact table lives in a source that must be queried live, but several small lookup dimensions are reused by both that fact and an Import fact. Cross-source queries are slow. Which configuration helps most?