Power BI row-level security vs object-level security
Row-level security vs object-level security in Power BI is a choice between two kinds of protection inside a semantic model. The first, often called RLS, decides which rows a reader may see. The second, often called OLS, decides whether a table or a column exists for that reader at all. So they answer different questions, and many models need both. Each one also has limits worth knowing.
- Rows versus objects
- Roles hold both
- Tested per role
Last updated
Power BI row-level security vs object-level security: which does what?
RLS filters data. An author creates a role and writes a DAX filter on a table. Then a member of that role sees only the rows that pass the filter. For example, a regional manager sees one region, while the report and its visuals stay the same for everyone.
OLS hides structure. Microsoft explains that it lets model authors secure specific tables or columns from report viewers. For a viewer without permission, it is as if the secured table or column does not exist. So even the name stays out of sight.
In short, RLS answers which records a person may read. OLS answers which fields a person may know about. A salary column is a classic OLS case, and a sales territory is a classic RLS case.
How do Power BI row-level and object-level security compare?
The rows follow Microsoft's articles on both features.
| Area | Row-level security (RLS) | Object-level security (OLS) |
|---|---|---|
| What it protects | Rows in a table | Whole tables or columns |
| How it is set | A DAX filter in a role | A permission on the object in a role |
| Where authors set it | Power BI Desktop | TMDL view or an external tool |
| What the reader sees | Fewer rows, same fields | No sign of the secured object |
| Effect on visuals | Totals reflect the visible rows | A visual on a hidden field fails |
| Typical use | Region, department or client scope | Salary, cost or personal data columns |
| Applies to | Report viewers | Report viewers |
Three limits that apply to both kinds of security
These points catch teams out more than any DAX detail.
Viewers only
Security roles restrict people who only view content. Workspace admins, members and contributors can edit the model, so the roles do not hold them back. Therefore readers should get the viewer role or reach reports through an app.
Roles need members
A role does nothing until someone belongs to it. After publishing, an admin adds users or security groups to each role in the service. We prefer groups, because staff changes then need no model edit.
The model is the boundary
Both features protect data inside the semantic model. They do not protect the source database or an exported file. So export settings and source permissions need their own review.
When is row-level security enough?
RLS is enough when every reader may see every field, but not every record. Sales teams, branch managers and client portals usually fit that description. Because the same report serves all of them, one file replaces many copies.
Two patterns exist. A static role hard-codes a value, such as one region per role. A dynamic role compares a column with the signed-in user's account, so one role serves everybody. We favor the dynamic pattern when the list of users is long, since a mapping table then carries the rules.
However, RLS does not hide a column. When a measure or a field reveals something sensitive in total, a row filter alone will not protect it.
When does a model need object-level security?
OLS is the answer when a field itself is sensitive. For example, a staffing model may hold pay data beside headcount. Most readers should analyze headcount, but only a few should know that pay columns exist. Microsoft names personal data and financial records as typical cases.
Design matters here. A visual that uses a secured column fails for a reader who lacks access, since the object is missing for that person. So we build separate pages or separate reports for the restricted fields, and we test each one under each role.
Setup also differs. Microsoft documents two routes for OLS rules: TMDL view, or an external tool such as Tabular Editor. Both features live within model roles, so we plan the two together. For hands-on help setting up role filters, see Power BI row-level security.
How we set up security roles in a semantic model
The order below keeps surprises out of the launch week.
Write the access rules
First we record, in plain words, who may see which rows and which fields. A business owner signs off on that list before any build.
Build the roles
Then we add row filters in Desktop and object rules where needed. We keep both kinds in the same role when one audience needs both.
Test as each role
Desktop and the service can show a report as a chosen role. So we open every page under every role and note what breaks.
Assign groups and hand over
Finally we map security groups to roles in the service. Your admin receives a short guide for adding and removing people.
Power BI row-level security vs object-level security: checks first
Six checks tell us which feature, or which mix, a model needs.
- Do readers differ by records or by fields?
- Does any column hold pay or personal data?
- Who holds edit rights on the workspace today?
- Can a mapping table tie users to their scope?
- Do security groups already exist for each team?
- Can readers export the underlying data?
Power BI row-level security vs object-level security: common questions
Can one Power BI model use row-level security and object-level security?
Yes. Both are part of model roles, so a single role can carry a row filter and an object rule. We keep the two in the same role for an audience that needs both, because mixing them across separate roles can lead to errors. Then we test each role before launch.
Does Power BI row-level security apply to workspace members?
No. The roles restrict users who only view content. Anyone with an admin, member or contributor role on the workspace can edit the semantic model, so the restrictions do not bind them. Therefore we give readers the viewer role or share through an app, and we keep edit rights narrow.
Is hiding a column the same as object-level security in Power BI?
No. A hidden column only disappears from the field list, and a determined user can still query it. OLS removes the object for a restricted viewer, including its name and metadata. So hiding is a tidiness feature, while OLS is a security feature. Sensitive fields need the second one.
Do we need a special tool for Power BI object-level security?
Not any longer. Microsoft documents TMDL view as a way to define OLS rules with a script, so an external tool is optional. Tabular Editor remains a documented route as well. Row filters, by contrast, have had a Manage roles dialog in Power BI Desktop for a long time.
How can Power BI Agency help with model security?
One of our consultants reviews your roles, workspace access and export settings in a free 30-minute assessment. We work inside your own tenant and explain each rule in plain words. Power BI Agency is a division of Sataware Technologies and independent of Microsoft. Call (480) 485-7373. We reply within 2 hours.
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.