Subscribe
Share
Share
Embed
A Power BI dashboard can show tiles from six different semantic models. It cannot filter a single one of them. We explain why the architecture makes that tradeoff inevitable, and what it means for choosing between dashboards and reports.
Episode 29 • 2026-07-17 Duration: 9:51
A Power BI dashboard can show tiles from six different semantic models. It cannot filter a single one of them. We explain why the architecture makes that tradeoff inevitable, and what it means for choosing between dashboards and reports.
AI-generated voices. Matthias — cloned voice. Fabia — designed AI co-host. See Matthias live on YouTube (Fabric Friday), at his meetups, and at conferences like FabCon.
Hosted by Matthias Falland — Microsoft Data Platform MVP and community architect behind the Fabric Periodic Table. New episodes every Friday.
Have an architecture decision you are wrestling with? DM Matthias on LinkedIn — find him as Matthias Falland. Three to five sentences about the decision, your team size, and your current stack. We anonymize before airing.
This podcast was generated by AI.
Brand design based on fabricperiodictable.com.
Architecture decisions for Microsoft Fabric. Anonymized real customer scenarios, cost realism, counter-arguments included. Weekly episodes aligned with Fabric Friday recordings.
Speaker 1
Three things in Fabric are called dashboard. They share a noun, nothing else.
Speaker 2
And the single most asked question on the community forums? Going back years, same phrasing, dozens of threads. Is about the most basic thing you'd expect a dashboard to do.
Speaker 1
Filtering. Architecture decisions for Microsoft Fabric. This is the Fabric Architecture Podcast.
Speaker 2
Today we're pulling that thread. Why the answer is architectural? What the snapshot underneath is actually doing and what it means for where you should and shouldn't build one. A Power BI report is bound to exactly one semantic model, hard constraint. Your CFO's Monday morning check needs revenue from the finance model, order backlog from ops, signups from web analytics. Three models. No single report can show all three A dashboard pins tiles from multiple reports, across multiple models, onto one canvas. It's the only Power BI artifact that can do this.
Speaker 1
So it's a cross-model aggregation service.
Speaker 2
It is, and it lives in the Power BI service only. You can't create one in desktop, can't build one in Report Server, can't author one on mobile View and share from mobile, yes. Author, only in the service.
Speaker 1
Which is already a surprise for most people I work with. They open desktop, look for the dashboard option, and it doesn't exist.
Speaker 2
We've got a question from the Microsoft Fabric Community Forums, and I'm reading it exactly as posted. How do I filter tiles on a dashboard in the Power BI service?
Speaker 1
That thread's not alone. Dashboard slicer, dashboard filter, pin filter pane. Same question, different words, years of threats.
Speaker 2
And the answer is, you can't. The architecture makes it inevitable. If tiles come from different semantic models, there's no guaranteed shared field to filter on. Region in the finance model might not exist in the ops model, or might carry different grain and keys. A slicer that works correctly across all tiles would need every model to agree on every filtered dimension. Nothing guarantees that. So the feature doesn't exist.
Speaker 1
And this is where requirements conversations go sideways. Someone says, build me a dashboard, and in the next breath says, I want to filter by region. They've described a report. I keep running into this. Catch it in requirements, not in sprint review
Speaker 2
The workaround is to pin an entire report page as a live tile. A live page is one semantic model by definition, so the slicers keep working inside that tile. But that workaround creates a conflict you'll hit about three weeks later.
Speaker 1
What conflict?
Speaker 2
A tile pinned from a single report visual is a snapshot. The dashboard stores the rendered visual definition as it was at pin time, plus a pointer to the semantic model. Data flows through the pointer on refresh. Shape does not. Change a line chart to a bar chart in your report. The tile stays a line chart. Conditional formatting dropped. The color rule lives in the report engine. The tile cache stores the rendered result, not the logic.
Speaker 1
So if I redesign my report, the dashboard just doesn't follow?
Speaker 2
The data follows. The visual definition doesn't. Delete the tile, repin it. There's no resync command.
Speaker 1
That'll generate some tickets.
Speaker 2
It already has. But here's the real conflict. You can set data alerts on individually pinned tiles, gauges, KPIs, and cards only. And you can get filtering by pinning a live page, but you cannot have both on the same tile. Pin Live. Filters work, alerts disappear. Pin Single. Alerts work, filters disappear. You're making an architectural decision the moment you click pin.
Speaker 1
That's the kind of constraint that should be on a whiteboard the first time someone touches this. Most people discover it when they go looking for the alert button and it's not there, and by then the dashboard's already in front of the CFO.
Speaker 2
And the snapshot architecture explains the refresh complaints too. Tile refresh is a different operation from data refresh, and the behavior splits three ways. Import models. Tiles refresh automatically with each data refresh, no separate step. Direct query or live connection. There's a separate tile refresh, roughly hourly by default And writes through the XMLA endpoint only invalidate the tile cache. They don't rebuild until someone actually opens the dashboard
Speaker 1
Wait, the first person in pays the full rebuild latency?
Speaker 2
Yes, that's deliberate. Rebuilding every tile cache for every user on every XMLA right would be enormously expensive tenant wide. On licensing. Creating a dashboard in a workspace needs pro or premium per user Viewing a shared one needs the same, unless the content sits in Premium or Fabric F64 or higher. MyWorkspace is free to create in, but the moment you share to a team workspace, you're paying.
Speaker 1
For the cross-model monitoring use case, which is the one that actually justifies building a dashboard, you're already in a workspace. Every creator needs Pro or PPU. Your viewers either need Pro themselves or F64 Plus capacity. By fabric standards the cost is modest. Just know it's there before you start pinning tiles from six different models.
Speaker 2
I want to steel man the dashboard here, because it gets dismissed too quickly. If you genuinely need to monitor KPIs across three or four semantic models on one screen, the dashboard is still the only Power BI artifact that does it without modeling changes The alternative is a composite model or a master semantic model that consolidates everything into one report. And that's a modeling commitment with real maintenance cost.
Speaker 1
I'd go further. For teams that need a status wall, five cards from five models. Nobody needs to interact. It sits on a monitor in the hallway. That's the cleanest tool for the job. Monitoring, yes. Analysis.
Speaker 2
But pair it with what the docs show about where investment is going. There's no deprecation notice for dashboards. I checked. Nothing. They're documented, supported, licensed as first class. But new alerting is landing on Activator, on Reports. Fabric Embed Preview supports real-time dashboards only. Fabric workspace item events explicitly list dashboard as unsupported. And the QA box, one of the dashboard's few exclusive features, retires December 2026.
Speaker 1
That's five months from now. So here's where I'd land. New project, someone says we need a dashboard. First thing I do is ask whether they mean the word or the item type. Nine times out of ten, they want filtering, drill through, multiple pages. That's a report. Build a report, call it a report, and never put dashboard in the name. Microsoft's own migration guidance warns against it, and every team that ignored it has a workspace where nobody can tell what's what.
Speaker 2
And when it genuinely is cross-model monitoring, pin individual visuals for the tiles you need alerts on, pin live pages for the ones you need filtering on, and accept the trade-off on each tile. Design the phone layout explicitly. Without one, tiles just stack vertically and your visual hierarchy disappears. Use a dashboard theme to unify formatting, because pinning strips most per visual formatting anyway.
Speaker 1
The vocabulary is the real problem here Every confusion I keep running into, can't filter, stale tiles, missing alert buttons, collapses once you understand one thing. A dashboard is a pinboard over cached snapshots from multiple models. Once you know that, you stop fighting it.
Speaker 2
Show me the query pattern. If the pattern is monitor five numbers from five models, the dashboard's exactly right. If the pattern is explore, filter, drill, you wanted a report from the start.
Speaker 1
Somewhere right now, someone's pinning a tile and wondering where the slicer went. And somewhere else, someone's pinning a live page and wondering where the alert button went. Same product, opposite complaints. Same snapshot underneath
Speaker 2
Both problems solve the moment you understand what you pinned.
Speaker 1
If you've hit one of these traps, DM me on LinkedIn. Find me as Matthias Falland.
Speaker 2
See you next Friday.
Speaker 1
This was the Fabric Architecture Podcast. This podcast was generated by AI. New episode every Friday.