Extensibility Layer Objects

Title slide. Welcome the audience, introduce the guide topic. *"Today we're covering extensibility layer objects: field parameters, calculation groups, what-if parameters, custom calendars, and disconnected tables. These are the objects that create composite model connections, letting you extend a shared semantic model for departmental or report-specific needs."*

**On screen:** Diamond/pyramid graphic with three stacked layers and corresponding layer bars (Report, Domain, Core). - Introduce the **three-layer architecture**: Core Semantic Model at the base, Departmental/Domain layer in the middle, Report layer on top - Core = shared business logic everyone uses. Domain = team-specific extensions via composite models. Report = single-report objects - The diamond visual shows how scope narrows as you go up, with fewer consumers and more specialized use cases *Transition: "Let's break down what belongs in each layer."*

**On screen:** "Core Model" card: Semantic Model tagline. - The foundation: Sales, Profit, YTD, and other metrics everyone needs across all reports - This is the **shared** semantic model: managed centrally, deployed once, consumed by many - Nothing extensibility-specific lives here; it's the baseline *Transition: "Now the middle layer: where extensibility objects typically land."*

**On screen:** "Departmental" card: Extensibility Layer tagline. - Composite model objects shared across multiple reports for a department or use case - Examples: a Finance calculation group (YTD, QTD, variance), a Sales field parameter - Key point: these live in a **separate PBIX** that connects to the core model via DirectQuery *Transition: "And the top layer: report-scoped objects."*

**On screen:** "Single Report" card: Report-Scoped tagline. - Objects unique to one report: dynamic titles, formatting measures, scenario sliders - These don't need to be shared; they're tailored to a specific analysis - Lowest governance overhead but also lowest reuse potential *Key message: Know which layer an object belongs to BEFORE you build it.*

**On screen:** Departmental Composite Models card with common patterns list. - A single composite model PBIX connects to the core semantic model and adds departmental objects - Other reports connect to THIS model, getting both core and departmental features - Walk through examples: Finance team calc group, Sales field parameter, custom fiscal calendar, Marketing attribution tables, HR headcount scenarios - Emphasize: one composite model serves the whole department *Transition: "Now the single-report pattern."*

**On screen:** Single-Report Composite Models card with common patterns list. - When extensibility objects don't make sense to share: one executive's scenario analysis, a specialized field parameter for one dashboard - Walk through examples: Executive KPI switcher, What-If budget slider, specialized time intelligence, Top N selector, one-off custom calendar - Key difference from departmental: no one else consumes this composite model *Transition: "So how do you decide which pattern to use? Three questions."*

**On screen:** Decision flow card: "Will others need this?" question with explanation. - First question in the decision flow: **Will others need this?** - If multiple reports need the same object, use the departmental pattern - If only one report ever needs it, keep it single-report scoped *Transition: "Second question..."*

**On screen:** "Is it experimental?" decision step. - Second question: **Is it experimental?** - Testing something new? Start with single-report: lower risk, easier to iterate - Once proven and validated, promote to departmental if others need it *Transition: "And the ownership question."*

**On screen:** "Who maintains it?" decision step. - Third question: **Who maintains it?** - Departmental models require shared ownership; someone has to own updates and testing - If there's no clear owner, single-report is safer *Key message: These three questions should be your checklist every time you build an extensibility object.*

**On screen:** Field Parameters card: teal header, "Dynamic field switching" subtitle. - Lets users switch which measure or column appears in a visual via slicer - One chart, many metrics on demand: KPI selector dashboards, dynamic axis switching - "Perfect For" list: KPI selectors, Month/Qtr/Year toggling, consolidating similar reports, "choose your metric" experiences - This is often the **first** extensibility object teams reach for *Transition: "Next: calculation groups."*

**On screen:** Calculation Groups card: blue header, "Measure transformations" subtitle. - Applies transformations (YTD, Prior Year, % of Total) to ANY measure automatically - One definition, universal application: write it once, it transforms every measure - "Perfect For" list: time intelligence, variance calculations, currency conversion, scenario switching - Emphasize: this object has the broadest reach (one definition modifies every measure) but requires the most DAX skill *Transition: "For scenario analysis, there's a simpler option."*

**On screen:** What-If Parameters card: orange header, "Scenario sliders" subtitle. - Creates numeric sliders for scenario analysis; users adjust values and see impact in real-time - Growth rate scenarios (0-50%), discount impact, headcount planning, threshold adjustments - Simplest extensibility object to implement: it is a built-in Power BI feature - Limitation: values reset each session (no persistence) *Transition: "Two more objects to cover."*

**On screen:** Custom Calendars card: teal header, "Specialized date tables" subtitle. - Adds specialized date tables for fiscal years, retail calendars, or custom period logic - Not in the source model? Add it via composite connection - "Perfect For" list: fiscal year calendars, retail 4-4-5/4-5-4, custom week definitions, holiday/working day logic - Watch out for relationship conflicts with existing date tables (covered in gotchas) *Transition: "And the most flexible object type."*

**On screen:** Disconnected Tables card: green header, "Standalone lookup tables" subtitle. - Standalone tables for slicer options, configuration values, or lookup data. NO relationships to the main model - "Perfect For" list: Top N selector, display mode toggles, sort order config, report-specific lookups - Key point: selections from disconnected tables require explicit measures (SELECTEDVALUE) to work - Most commonly created via "Enter Data" button *Transition: "One more option that doesn't even need a composite model."*

**On screen:** Visual Calculations callout card: green accent, "NO COMPOSITE" badge. - Visual Calculations are report-scoped DAX that work entirely within a single visual - **No composite model created**: running totals, rankings, percent of parent, moving averages - Limitation: they only exist within the visual where they're created and cannot be reused - Position this as the "free" alternative when you don't need cross-visual functionality *Key message: Before reaching for composite model objects, check if Visual Calculations solve the need.*

**On screen:** Feature comparison table: 5 object types across 4 feature rows. - Walk through each row: - **Works in Excel**: Field Params and What-If do NOT work in Excel PivotTables; this is a big deal for orgs that rely on Excel - **Can have relationships**: Only Field Params and Custom Calendars can form relationships - **DAX/M knowledge**: ranges from Basic to Moderate; Calc Groups and Custom Calendars require more skill - **Code Language**: mostly DAX, but Disconnected Tables can be M (Enter Data) and Custom Calendars can be either *Transition: "A couple of footnotes worth mentioning."*

**On screen:** Footnotes info box with superscript explanations. - Footnote 1: Disconnected tables "usually" work in Excel because SELECTEDVALUE/SWITCH measures handle slicer selections; it depends on the measure pattern, not the table itself - Footnote 2: Disconnected tables are commonly created via "Enter Data" (M code), but can also use DAX DATATABLE functions - These nuances matter when advising teams on which objects to use *Key message: The comparison table is your quick-reference cheat sheet. Screenshot it.*

**On screen:** Benefits card (green): 6 bullet points. - Walk through the benefits of extensibility layer objects: - **Enhanced interactivity**: dynamic user experiences without model redeployment - **Rapid iteration**: test ideas without waiting for central model changes - **Self-service enablement**: report authors can add features themselves - **Report-specific logic**: tailored calculations that don't pollute the core model - **Clean core model**: report clutter stays in reports - **Scenario analysis**: What-if capabilities that the core model shouldn't own *Transition: "But there are real considerations to weigh."*

**On screen:** Considerations card (red): 6 bullet points. - Walk through the considerations: - **Composite model layer**: adds a DirectQuery connection, which is an architectural cost - **Refresh behavior changes**: may differ from pure import mode - **Feature limitations**: some Power BI features are restricted in composite mode - **Field params break upstream**: they don't work if another report DQs to yours - **Maintenance overhead**: business logic now lives in multiple places - **Testing required**: always verify behavior after adding extensibility objects *Key message: These trade-offs are manageable. The goal is to go in with eyes open, not to avoid extensibility objects entirely.*

**On screen:** Green accordion: "No/Minimal Impact" tier (Field Parameters, What-If, simple Disconnected Tables). - **Field Parameters** just switch between existing measures, adding no additional query complexity - **What-If Parameters** and simple Disconnected Tables have no model relationships; they pass a value via SELECTEDVALUE() at negligible cost - These are the "safe" objects from a performance standpoint *Transition: "The middle tier has some nuance."*

**On screen:** Yellow accordion: "Low to Medium Impact" tier (Calculation Groups, Complex Disconnected Tables). - **Calculation Groups** modify query behavior by wrapping measures; simple time intelligence adds minimal overhead - Complex DAX or poorly structured CG items can increase cost; rare cases create unexpected many-to-many patterns causing timeouts - **Complex Disconnected Tables** with heavily nested SWITCH statements accumulate overhead from the DAX complexity, not from the table itself *Transition: "And the tier that needs the most planning."*

**On screen:** Red accordion: "Higher Impact" tier (Custom Calendars, Nested Composite Models). - **Custom Calendars** introduce actual model relationships; performance depends on relationship type, cardinality, and interaction with existing date logic - The calendar table itself is rarely the bottleneck. It's the complex fiscal year DAX that accompanies it - **Nesting Composite Models** compounds DirectQuery overhead; each layer adds latency. Never chain Report A to Composite B to Composite C *Key message: Performance impact is mostly about DAX complexity and relationship design, not the objects themselves.*

**On screen:** "Dynamic Switching Needed" positive card: Field Parameters and Calc Groups tags. - Users need to toggle between measures, columns, or time calculations without multiple visuals - Field Parameters for switching metrics/columns; Calc Groups for switching time intelligence or transformations - Classic scenario: "I want one chart that can show Revenue, Units, OR Margin" *Transition: "Next use case."*

**On screen:** "Scenario Analysis" positive card: What-If Parameters tag. - What-if analysis and sensitivity testing; users adjust numeric parameters in real-time - Budget scenarios, growth projections, discount impact modeling - The slider-based UX makes it intuitive for business users *Transition: "Specialized time logic."*

**On screen:** "Specialized Time Logic" positive card: Custom Calendars and Calc Groups tags. - Custom calendar periods, fiscal years, or time intelligence not available in the core model - Example: the core model uses calendar year, but Finance needs April-March fiscal - Combine Custom Calendars with Calc Groups for powerful time intelligence *Transition: "And report-specific configuration."*

**On screen:** "Report-Specific Configuration" positive card: Disconnected Tables tag. - Slicer options, Top N selectors, or lookup values that only apply to this specific report - Low complexity, low risk: great starting point for self-service authors - Example: "Show me Top 5, 10, or 20 products." That selector doesn't belong in the core model *Transition: "Now the situations to avoid."*

**On screen:** "Excel Connectivity Required" negative card: Field Parameters and What-If tags. - If users need to analyze data in Excel PivotTables, these objects break connectivity - This is a hard limitation with no workaround. Know your audience before adding these objects. - Ask: "Does anyone consume this model in Excel?" before adding Field Params or What-If *Transition: "Another anti-pattern."*

**On screen:** "Chaining Composite Models" negative card: All Objects tag. - If other reports will DirectQuery connect to YOUR composite model, you're creating a chain - Report A connects to Composite B connects to Composite C: fragile, slow, hard to debug - Rule of thumb: composite models should connect to the core model, not to other composites *Transition: "And the most important one."*

**On screen:** "Core Business Logic" negative card: All Objects tag. - If the calculation defines universal business rules, it belongs in the semantic model - "Net Revenue" isn't an extensibility object. It's core business logic - The extensibility layer is for enhancements and customizations, not foundational metrics *Key message: The line between "core" and "extension" is harder than building the objects themselves. Decide before you build.*

**On screen:** "Start with Single-Report" tip card. - Test new patterns in a single report first: lower risk, faster iteration - Promote to departmental only when proven AND others need it - This is the "prototype first" philosophy applied to data modeling *Transition: "Next tip."*

**On screen:** "Document Your Architecture" tip card. - Create a diagram showing Core Model, Departmental Models, and Report connections - Without this, teams won't understand the dependency chain - Even a simple Visio/draw.io diagram prevents "where does this object live?" confusion *Transition: "Testing matters."*

**On screen:** "Test Composite Behavior" tip card. - After adding objects that create composite models, test refresh and verify all features still work - Some features behave differently in composite mode vs pure import - Build a quick validation checklist: refresh, cross-filter, drill-through, export *Transition: "Think about reuse."*

**On screen:** "Consider Future Reuse" tip card. - If you find yourself copying the same object to multiple reports, it's time to create a departmental model - Copy-pasting is a code smell in data modeling just like in software development - The "rule of three" applies: copied to 3 reports? Promote it. *Transition: "Discoverability tips."*

**On screen:** "Surface Key Objects at Top" tip card. - Use a dot prefix to sort calc groups and field parameters to the top of the field list - Example: ".Time Intelligence" sorts above all other tables alphabetically - Users can't use what they can't find. Discoverability is half the battle *Transition: "And naming conventions."*

**On screen:** "Name with Type and Intent" tip card. - Use a clear pattern like ".Calc Group - Time Intelligence" or ".Parameter - Metric Selection" - Users should know what each object does at a glance from its name alone - Consistent naming across the organization reduces training overhead *Key message: Good naming and organization are as important as the objects themselves.*

**On screen:** "Field Parameters Don't Pass Downstream" gotcha card. - If another report connects to your composite model via DirectQuery, your field parameters won't be available - They only work within the report where they're defined. This is the most common surprise - Plan for this: if downstream reports need the switching, use Calc Groups instead *Transition: "Next gotcha."*

**On screen:** "Calculation Group Precedence" gotcha card. - When multiple calculation groups are applied simultaneously, precedence rules determine evaluation order - This can cause unexpected results, for example when applying "YTD" and "Currency Conversion" together - Always test CG combinations and document the expected precedence order *Transition: "A UX gotcha."*

**On screen:** "What-If Values Reset Each Session" gotcha card. - User selections on What-If parameter sliders don't persist between sessions - Every time a user opens the report, the slider resets to its default value - Set sensible defaults and document this behavior for end users; they WILL ask *Transition: "Calendar conflicts."*

**On screen:** "Custom Calendar Relationship Conflicts" gotcha card. - If the source semantic model already has a date table marked as "date table," adding another can create ambiguous relationships - Plan your relationship strategy carefully: which date column connects where? - Consider using inactive relationships and USERELATIONSHIP() for secondary calendars *Transition: "Disconnected table gotcha."*

**On screen:** "Disconnected Tables Need Explicit Measures" gotcha card. - Selections from disconnected tables don't automatically filter data - You MUST use SELECTEDVALUE() or similar functions in your measures to respond to selections - Common mistake: creating the table, adding the slicer, and wondering why nothing happens *Transition: "And the timing gotcha."*

**On screen:** "Composite Model Refresh Timing" gotcha card. - Local model data (disconnected tables) and remote semantic model data may have different refresh schedules - This can lead to data inconsistency during certain windows; for example, local config says "show top 10" but the underlying data hasn't refreshed yet - Document refresh dependencies and consider scheduling local refreshes to follow core model refreshes *Key message: None of these gotchas are surprising once you know about them. Plan for them before building, not after users file tickets.*

Feature	Field Params	Calc Groups	What-If	Custom Cal	Disconn. Tables
Works in Excel	No	Yes	No	Yes	Usually¹
Can have relationships	Yes	No	No	Yes	N/A
Requires DAX/M code knowledge	Basic	Moderate	Basic	Moderate	Basic
Code Language	DAX	DAX	DAX	DAX or M	M² or DAX

Extensibility Layer Objects

The Three Layers

Core Model

Departmental

Single Report

Departmental vs Single-Report Patterns

Departmental Composite Models

Common Patterns

Single-Report Composite Models

Common Patterns

Which Pattern Should I Use?

Will others need this?

Is it experimental?

Who maintains it?

Objects That Create Composite Models

What It Does

Use When

What It Does

Use When

What It Does

Use When

What It Does

Use When

What It Does

Use When

Don't Need a Composite Model? Consider Visual Calculations NO COMPOSITE

Feature Comparison

The Trade-Off Analysis

Benefits

Considerations

Performance & Query Behavior

No/Minimal Impact

Low to Medium Impact

Higher Impact

Choosing the Right Object

Use These Objects When...

Dynamic Switching Needed

Scenario Analysis

Specialized Time Logic

Report-Specific Configuration

Avoid These Objects When...

Excel Connectivity Required

Chaining Composite Models

Core Business Logic

Practical Conventions for Extensibility Objects

Start with Single-Report

Document Your Architecture

Test Composite Behavior

Consider Future Reuse

Surface Key Objects at Top

Name with Type and Intent

Common Gotchas

Field Parameters Don't Pass Downstream

Calculation Group Precedence

What-If Values Reset Each Session

Custom Calendar Relationship Conflicts

Disconnected Tables Need Explicit Measures

Composite Model Refresh Timing