Free Power BI Row-Level Security (RLS) DAX Generator
Describe who should see what, in plain English — get back a real RLS filter expression ready to paste into Manage Roles, static or dynamic per signed-in user.
How Power BI row-level security actually works
An RLS role is just a DAX filter expression on a table that evaluates to TRUE or FALSE for every row — only the rows that come back TRUE are visible to anyone assigned that role. You define roles in Power BI Desktop (Modeling > Manage Roles), then assign real users or security groups to them after publishing, in the Power BI service.
Static vs. dynamic RLS
A static rule is a fixed value, like [Region] = "West" — one role per group, reassigned by hand as people change teams. A dynamic rule filters differently for every signed-in user from a single role definition, usually [UserEmail] = USERPRINCIPALNAME() matching a mapping column against the viewer's own sign-in email — far less maintenance once you have more than a handful of groups.
A worked example
Describe: "each regional manager should only see their own region's sales." This generates a dynamic filter — a mapping table matches USERPRINCIPALNAME() to a region, and the Sales table's own Region column is filtered against it — so one role, assigned to every manager, correctly shows each of them only their own data.
Always confirm the result with Power BI Desktop's own View as role feature before publishing — see Microsoft's own row-level security documentation for the full reference.
Questions
Is this free?
Yes, completely free, no account or signup needed.
Where do I actually paste this?
In Power BI Desktop: Modeling > Manage Roles > New, pick the table, switch to the DAX filter editor, and paste the expression in. Save, then assign real users to the role after publishing, in the Power BI service.
What's the difference between USERPRINCIPALNAME() and USERNAME()?
USERPRINCIPALNAME() returns the signed-in user's email-style UPN (e.g. [email protected]) and is the more common choice. USERNAME() returns a DOMAIN\user form in Desktop, but both resolve to the same UPN format once published to the Power BI service — most new setups should use USERPRINCIPALNAME().
Can RLS hide specific columns instead of rows?
No — RLS only restricts which rows a user sees; anyone with access to a row sees every column in it. Hiding specific columns needs object-level security (OLS) instead, a separate feature.
Does this need my actual data model?
No — just describe the rule in plain English. If you name real table/column names it uses them exactly; otherwise it picks sensible placeholder names and says so in the explanation, so you know what to rename before pasting it in.
Need the whole dashboard, not just a security rule?
Upload your data, describe what you want, and get back a real, editable .pbip project today — free, no Fabric or Copilot license needed.
More free tools: DAX formula generator · DAX explainer · DAX cheat sheet · see all →