09/30/2026
At most companies, the Power BI security model is a person in finance with a distribution list.
Build the report. Filter a copy for each manager. Email nine files. Do it again next month.
Nobody chose that system. It's what happens when one shared report can't be trusted to show each person only their own numbers.
The reason sits upstream of Power BI.
Row-level security, the feature that lets a CFO and a branch manager open the same report and see different rows, filters a table. The filter then travels through the model's relationships to everything connected to it. Microsoft's guidance says it in one line: RLS filters only propagate through active relationships.
Now look at one branch across a typical stack:
ERP: E100-COL
CRM: Columbus OH
Payroll: Dept 4410
Warehouse: WH-02
Four names for one building, and no shared list for a security rule to hold onto.
So teams write a rule per system and miss one. Or they build a report per region and watch the copies drift. Or they go back to the distribution list.
Map all four to one governed record and a single rule, Region = East, filters revenue, pipeline, labor and inventory at once. The CFO, two regional VPs, a branch manager and a board member open the same report. Each one sees their own rows. Nobody gets a file.
That's the order that works. Crawl gets every system to agree. Walk puts governed Power BI on top of it. Run points AI at the same model, under the same rules.
Security follows the model. Build the model first.
Full breakdown, including the five-view report table: https://bit.ly/4hFuILN
Power BI governance lives in the data model, not the admin portal. How normalized source data lets one set of row-level security rules govern every report.