Power BI row-level security, designed, tested and documented
Power BI row-level security lets one report serve many audiences, while each person sees only their own rows. However, it works only when one design covers roles, relationships and workspace permissions. So we plan who sees what and build static or dynamic roles. Then we test every role before anyone gets access, and document the rules for your team.
- Access matrix agreed first
- Dynamic roles from a mapping table
- Every role tested
Last updated
How does row-level security work in Power BI?
A role is a set of DAX filters on tables in the semantic model. When a member of that role opens a report, Power BI applies the filters to every query. Then relationships carry the filter to related tables.
You create roles in Power BI Desktop. Then you assign members in the Power BI service, either as users or as Microsoft Entra security groups. Groups are easier to maintain, because access then follows your existing directory.
Static roles hard-code a value, for example Region equals West. They are simple but multiply quickly. Dynamic security instead matches USERPRINCIPALNAME() against a mapping table, so one role serves everyone.
Power BI row-level security patterns we build
Most real requirements combine two or more of these patterns.
Territory and region
Sales and service teams see their own area, and managers inherit the areas below them.
Manager hierarchies
DAX path functions let a manager see their own records and those of everyone reporting to them.
Department and cost center
Budget holders see their own spend and headcount, while finance keeps the full view.
Customer-facing embedding
With app-owns-data embedding, the identity in the embed token applies each customer's role.
Hidden columns and tables
Object-level security, set with a tool such as Tabular Editor, removes fields like salary for some roles.
Users in several roles
When one person holds several roles, we design the filters so the combined access is exactly as intended.
Why do workspace roles matter as much as the model?
One detail catches many teams out. Row-level security restricts only people with Viewer access, or those who receive content through an app or sharing. Admins, Members and Contributors see all data.
So power bi workspace roles are part of the security design, not an afterthought. Report readers belong in an app audience or the Viewer role, never in Member just to open a report.
The same rules matter for power bi embedded, where your application passes each customer's identity in the token. Labels add another layer. Power bi sensitivity labels mark confidential content and travel with exports.
Power BI row-level security setup in four steps
We design and prove the security before anyone gets access.
Write the access matrix
A plain table of user groups and the data each may see, agreed in writing with the data owners.
Model the security
Next, the mapping table, roles and filter direction go in, with expressions kept simple so reports stay fast.
Test every role
View as in Desktop and Test as role in the service, with totals checked for each group.
Assign and document
Finally, we map security groups to roles, review workspace access and write a runbook for adding users.
Signs your Power BI security needs a review
If any of these sound familiar, the current setup is worth checking.
- Separate copies of one report for each region or customer
- Dozens of static roles that nobody wants to touch
- Users added as workspace Members just to see a report
- Reports that slow down sharply once security applies
- No record of who can see which data, or why
- Sensitive columns hidden in visuals but still in the model
Power BI row-level security questions
Does Power BI row-level security work with DirectQuery?
Yes. The role filters apply to the queries sent to the source. For some sources, single sign-on can also pass the user's identity to the database. Then the database applies its own security rules as well. We test both layers together, so they never contradict each other.
Will security slow our reports down?
Simple filters on a well-built star schema add little overhead. However, complex expressions or bi-directional filtering can hurt performance. That is why we test speed as well as correctness for every role. If a role is slow, we simplify its filter before launch.
Can we manage access without editing the model?
With dynamic security, yes. Access lives in a mapping table or follows Microsoft Entra security groups. So adding a user becomes a data change or a group change, not a model change. Your team receives a runbook that explains each step.
Can you review Power BI security we already have?
Yes. We audit existing roles, workspace permissions and sharing links. Then we report what each group can really see, in plain language. Any gaps come with a ranked fix list, so your data owners can decide what to change first.
How does a security project start?
With a free 30-minute assessment. One of our consultants replies within 2 hours and reviews your access needs. Then you receive a written quote with a fixed scope. We work inside your tenant through accounts you control and do not copy data to our own systems.
Related pages
Let's build your first dashboard together.
Tell us what you report on today. A consultant replies within 2 hours with next steps.
Trusted partners
Microsoft Solutions Partner · AWS Partner
Cloud & AI Platforms
Azure SQL, Microsoft Fabric and the data pipelines behind your reports.
AI Business Solutions
Power BI reporting on your Dynamics 365, Business Central and Power Platform data.
Security
Row-level security and Entra ID sign-in on every report and workspace.
Amazon Web Services
Power BI on your AWS data, with connectors for Redshift, Athena and S3.