Subscribe
Share
Share
Embed
A scorecard silently creates its own semantic model the moment you hit New. That one architectural fact — that it's a stateful writer, not a read-only lens — explains why RLS doesn't carry over, why refresh breaks upstream, and why rollups leak across permission boundaries.
Episode 31 • 2026-07-31 Duration: 10:32
A scorecard silently creates its own semantic model the moment you hit New. That one architectural fact — that it's a stateful writer, not a read-only lens — explains why RLS doesn't carry over, why refresh breaks upstream, and why rollups leak across permission boundaries.
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
Every time you create a scorecard in Power BI, it silently creates a second semantic model in your workspace
Speaker 2
A second model just from hitting new scorecard?
Speaker 1
Owners, targets, check-in notes, status snapshots. None of that exists in your warehouse. Power BI has to persist it somewhere.
Speaker 2
Architecture decisions for Microsoft Fabric. This is the Fabric Architecture Podcast. So the thing that looks like a dashboard widget is actually its own data store.
Speaker 1
And that one architectural fact explains every limitation people keep running into. The RLS that doesn't carry over, the refresh that won't fire, the roll-up that leaks numbers across permission boundaries. Today we're pulling that thread all the way through. The most common pattern is a connected goal, the current values bound to a specific data point in a report visual, and updates whenever the semantic model refreshes. You can also roll values up from subgoals or type them in manually during a check-in. But current value and target are configured independently. Which means you often get a connected current chasing a manually typed target.
Speaker 2
Which is what every OKR actually looks like. The data says where you are, a person decided where you should be.
Speaker 1
But the binding target matters. A goal connects to a report visual, never directly to a semantic model, never to a lake house.
Speaker 2
Why can't I just point it at a measure?
Speaker 1
Because a measure's ambiguous until you pin down its filter context. Total sales means nothing until you say sliced how, filtered to what A report visual is a measure plus a fully materialized filter context. That's the contract that eliminates the ambiguity.
Speaker 2
So if nobody put a measure on a report page, I can't track it as a goal.
Speaker 1
Correct. You have to visualize it before you can track it. Real friction cost, and it surprises teams late in a rollout.
Speaker 2
The thing that actually justifies the overhead is the check-in. A check-in writes a date, a value, a status, and a note where you can add mention someone. That's the only place in the entire Power B i stack where a human being's judgment about a number lives right next to the number itself.
Speaker 1
For connected goals, the check-ins degraded. You can't type the value, it's locked to what the model says. But the note and status field stay writable. Because why revenue dropped 12% is never in your semantic model. We deliberately pause the German campaign. That's a human sentence, and the scorecard's the only artifact that stores it.
Speaker 2
What I keep running into though is Teams that adopt scorecards and then nobody does the check-ins. A scorecard nobody checks into is strictly worse than a KPI visual. It looks authoritative while being stale. You've added governance overhead and gotten nothing back for it.
Speaker 1
Worse than nothing. You've created a second semantic model that now needs to be governed, refreshed, and permissioned. If nobody's writing to that store, you're paying rent on an empty apartment. We got a question from the Fabric Community Forums that cuts right into this. Goals, metrics, doesn't support row level security, RLS.
Speaker 2
Discovered late in the rollout, I'm guessing.
Speaker 1
Usually. The docs confirm it flatly. Goals don't support RLS. The reason comes back to the same statefulness. RLS filters rows at query time on the source model. But the goals value was already snapshotted into the scorecard's own semantic model, under the connection owner's identity, before any viewer showed up. There's no row left to filter. The security boundary was crossed at snapshot time.
Speaker 2
So the feature that makes it useful, that it remembers, is exactly why RLS can't work.
Speaker 1
And with rollups, it gets sharper. The docs say rollups always show the same aggregation value of all sub-goals, regardless of goal level permissions If a parent goal is a sum and a user can see four of five children, they subtract and get the fifth.
Speaker 2
So a roll-up parent is never a confidentiality boundary.
Speaker 1
What you use instead is goal level permissions, roles with view and update access per goal. Genuinely different model from RLS, and you need to design for it that way from the start. The other thing the community won't stop asking about is refresh. Thread after thread going back years, my scorecard stopped updating. And the answer is almost always upstream. The scorecard sits at the end of a chain. Source, then semantic model refresh, then report visual, then connected goal, then daily snapshot. No scheduled refresh on the semantic model means nothing below it ever moves.
Speaker 2
And people debug the scorecard because that's where they see the symptom.
Speaker 1
Two hops upstream from the actual break. There's also a trap with push semantic models. Goals connected to a push model don't update automatically. That's by design, and there's no setting to change it. And the snapshot cadence is maximum daily, last value of the day retained. If you need subdaily reaction to a threshold breach, the scorecard's architecturally the wrong tool That's data activators job.
Speaker 2
The cost side needs to be on the table too. Authoring requires pro. Viewing requires either a pro license for every viewer. or you sit the scorecard on an F64 or larger capacity so free users can consume it. If you've got an executive scorecard read by 200 people That F64 is your only realistic path. And you need to model that cost before you promise the rollout. Because the alternative is 200 Pro licenses nobody's going to approve.
Speaker 1
And the official docs link to a community PowerShell script for bulk goal refresh. When the product's own documentation points you at a community script for automation, That's an honest signal about where the product's refresh story sits today.
Speaker 2
I want to steel man the KPI visual for a second. If you don't need an owner, don't need check-in history, and just want a number against a threshold on a wall-mounted screen, The KPI visual does that job. It's been in Power BI from the beginning and it creates zero governance overhead. No second semantic model, no permissions model to maintain, no refresh chain to debug.
Speaker 1
That's the correct choice for more teams than you'd expect. The scorecard wins precisely when the board asks, why did we miss Q2? And the answer needs to include who flagged it at risk in week three and what they wrote down. If nobody's ever going to ask that question, you don't need a scorecard.
Speaker 2
Pattern dictates platform.
Speaker 1
Worth knowing, metric sets were retired in November 2025. Scorecard hierarchies and the heat map view were removed in April 2026. Two retirements in this feature area inside a year, but scorecards themselves survived both calls, and that's meaningful signal about which items Microsoft considers load-bearing. If you're building governance on any Power BI item type, check its lifecycle status first.
Speaker 2
The risk I genuinely flag for any team adopting this, the roll-up forward-only rule. Switch an aggregation from sum to average in July, your January through June history still shows sums. Permanent discontinuity never backfilled. And there's a history loss trap that's worse. If the person creating the roll-up isn't the same person who owns the goal connection, your connected history gets deleted. Silently.
Speaker 1
Same person does both or the chart goes blank and nobody told you why.
Speaker 2
So the lesson from all of this A scorecard's the right tool when you need to know who promised what and what they said when it slipped. That's a real job and no visualization can do it. But you're signing up for a second semantic model, a permissions model that isn't RLS, a refresh chain that breaks upstream of where you see the symptom, and a daily cadence you can't accelerate. If the check-ins won't happen, don't create the scorecard. The KPI visuals cheaper and at least it's honest about being stateless.
Speaker 1
The trick almost nobody uses, the scorecard's auto-generated semantic model, is queryable. Point a paginative report at it and you get the printable, subscribable board pack the scorecards UI can't produce. There's no print button. Publish to web is blocked. But the snapshot history sitting right there in a model you can report on.
Speaker 2
Last week's episode and this week's episode clicking together.
Speaker 1
Somewhere right now, a scorecard with 40 goals is showing all green because nobody's checked in since March The status rules haven't re-evaluated because there's no scheduled refresh on the semantic model underneath. And it looks perfectly fine.
Speaker 2
That's the one I'd lose sleep over. If this hit home, find me on LinkedIn. I'm Matthias Falland.
Speaker 1
Architecture is not religion. Pick the tool that fits the job you actually have.
Speaker 2
This was the Fabric Architecture Podcast. This podcast was generated by AI. New episode every Friday