Practice — Medium · Solution

Part 1 — the leak, hunted

With returns → stores deleted, the Midwest role narrows revenue, targets, and every sales-side visual — while the returns card holds at the company-wide 8,334 units and the return-rate figures go quietly wrong (Midwest revenue over company returns: a ratio of mismatched scopes). The leak list is exactly the set of visuals whose facts the Regions filter can no longer reach. Repairing the relationship empties the list. The mapping is literal: an RLS leak is a filter-flow gap with a security badge, and Model view is where both are diagnosed.

Part 2 — the dynamic pattern, read

The mechanism: sign-in email → USERPRINCIPALNAME() → the filter keeps that manager's row(s) in employees → and for that to narrow sales, the filtered employees table must be able to filter the sales fact — meaning a filter path must run employees → (something) → sales.
The snag: employees sits on the many side of employees → stores, and filters flow one-to-many, from stores into employees — not out of it. A filtered employees table does not, by default, push its filter up into stores and onward to sales. A dynamic-RLS mapping table must sit where its filter can flow into the facts — in practice: a small user-to-region mapping related TO the Regions dimension (or configured with the specific cross-filter treatment this course has otherwise avoided, which is exactly why it is a recognize-not-build topic this week). Structure first, DAX second — even in security.

Reflection answers

The rule: View-as testing audits every fact, not the headline card. A role can be perfectly correct for the fact you watch and leaking on the one you don't — so the audit walks each fact family (sales, returns, targets, inventory) under each role, with predicted values where they exist.
One sentence: because it is on the many side of its relationship, a filter applied to employees stays in employees — the mapping table's whole job is to sit at a one-side where its filter flows downhill into the facts.