What is OOLS in Power BI?

If you're managing Power BI reports for different teams, you've likely faced the challenge of showing the right data to the right people. Object-Level Security, or OLS, is a powerful feature designed to solve exactly that problem by letting you control who sees specific tables or columns within your reports. This article will show you what OLS is, how it differs from Row-Level Security, and provide a clear, step-by-step guide to setting it up.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

What Exactly Is Object-Level Security (OLS)?

Object-Level Security (OLS) lets you hide entire tables or columns in your Power BI reports from specific user groups or roles. Think of it like a restricted document. While some people get to see the entire file, others receive a version with certain paragraphs or pages removed entirely. OLS applies this concept to your data model.

For example, imagine you have a comprehensive sales report containing revenue, units sold, salesperson names, and profit margins. You want your executive team to see every piece of data, but you don't want the individual sales reps to see the sensitive profit margin column. With OLS, you can create a rule that makes the ProfitMargin column completely invisible to the "Sales Reps" role while remaining fully visible to the "Executives" role.

For the sales reps, it’s not that the profit margin data is filtered - it’s as if the column never existed in the data set to begin with. This prevents confusion and protects sensitive information without forcing you to create and maintain multiple versions of the same report.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

OLS vs. RLS: Understanding the Difference

Before diving deeper into OLS, it’s important to distinguish it from its well-known counterpart, Row-Level Security (RLS). While both are used to secure data, they operate on different levels of your data model.

Row-Level Security (RLS), as the name implies, filters the rows of data a user can see. It’s perfect for when you want users to see the same report structure but only the data specifically relevant to them.

• Example: A regional sales manager for North America logs in to a global sales dashboard. RLS ensures they only see the sales data (rows) for the United States and Canada. They see the same columns as everyone else - Revenue, Units, Date - but only the records pertinent to their region.

Object-Level Security (OLS), on the other hand, hides the objects themselves - meaning entire tables or columns.

• Example: In that same global sales dashboard, perhaps there's a Customer_Contact_Info table and a Deal_Profitability column. You can use OLS to hide the entire Customer_Contact_Info table from the regional managers while also hiding the Deal_Profitability column from junior sales staff. They still see the rows relevant to them (thanks to RLS), but certain columns and tables are completely gone from their view.

Key Differences at a Glance:

• Scope: RLS filters rows. OLS hides columns or tables.
• Use Case: RLS is about personalizing data to a user's role (e.g., "see your own sales"). OLS is about protecting sensitive data types (e.g., "do not show salary or profit information to this group").
• End-User Experience: With RLS, aggregated totals in visuals will change based on the filtered rows. With OLS, visuals may break entirely if they rely on a column or table that is now hidden, or they will simply render without that information.

Often, the most robust security models combine both. You might use RLS to ensure sales reps see only their sales rows and OLS to hide the profit margin column within those rows.

Why Should You Use OLS? Practical Scenarios

So, when would you actually need to use Object-Level Security? Here are a few common scenarios where OLS becomes incredibly useful.

1. Hiding Sensitive Financial Metrics

Scenario: You've built a central finance dashboard that shows revenue, operational costs, employee salaries, and net profit margin. Your leadership team needs full visibility, but you want to share revenue and cost data with department managers without exposing salaries or profit margins.

Solution:

• Create a role called "Department Managers."
• Apply OLS to hide the Employee_Salaries table and the Net_Profit_Margin column for this role.
• Now, when department managers view the report, they can analyze their team's revenue and costs to manage their budgets, but the highly sensitive metrics are completely hidden from their view.

2. Securing Personally Identifiable Information (PII)

Scenario: An HR business partner builds a report on employee attrition that includes employee names, contact information, tenure, salary history, and performance review scores. They need to share trends about tenure and performance with team leads but must protect private PII like contact details and salary.

Solution:

• Create a "Team Leads" role.
• Use OLS to hide columns like PhoneNumber, HomeAddress, and Salary.
• The team leads can now use the dashboard to identify performance patterns or retention risks without ever having access to PII that falls outside their need-to-know.

Graphed

Build AI Agents for Marketing

Build virtual employees that run your go to market. Connect your data sources, deploy autonomous agents, and grow your company.

Build Your First Agent

3. Simplifying Reports for Different Audiences

Scenario: A marketing team's "master dashboard" is packed with dozens of granular metrics: click-through rates, cost per click, bounce rates, conversion A/B test results, and more. It empowers the marketing specialists but is overwhelming for the executive team, who only want to see top-level ROI.

Solution:

• Create an "Executive View" role.
• Apply OLS to hide all the granular "in-the-weeds" columns. Keep high-level metrics like Total_Ad_Spend, Total_Conversions, and Marketing_ROI_Percentage.
• This provides a clean, summarized version of the report for VPs and C-level execs, helping them make strategic decisions quickly without getting bogged down in detail.

A Step-by-Step Guide to Implementing OLS in Power BI

Setting up OLS is an advanced task that requires an external tool called Tabular Editor. You cannot configure OLS using only the Power BI Desktop interface. Don’t worry, it's a widely used and powerful tool in the Power BI community.

Pre-requisites:

• Power BI Desktop installed.
• Tabular Editor installed. You can install it from its official website. Once installed, it will appear in the "External Tools" ribbon in Power BI Desktop.

Step 1: Create Your Data Model in Power BI

First, build your report in Power BI Desktop as you normally would. Import your tables, establish relationships, and create your measures and visuals. For this example, let's assume we have a simple sales table with columns: Date, Product, Revenue, Cost, and Profit.

Step 2: Define Roles in Power BI Desktop

Next, you need to define the user roles that will determine who sees what.

1. On the Modeling tab in Power BI Desktop, click Manage Roles.
2. Click Create to add new roles. Let's create two: "Admin" (who will see everything) and "Analyst" (who will not see the Profit column).
3. Leave the DAX filter expressions blank. We are setting up OLS, not RLS.
4. Click Save.

Step 3: Open Your Model in Tabular Editor

This is where the magic happens.

1. Go to the External Tools ribbon in Power BI Desktop.
2. Click on Tabular Editor. This will open your currently active data model within the Tabular Editor interface.

Step 4: Configure Object-Level Security on a Column

Let's hide the Profit column from our "Analyst" role.

1. In Tabular Editor’s explorer pane on the left, navigate down to your table. Expand it to see the columns: Tables > Sales > Columns > Profit.
2. Click on the Profit column to select it.
3. In the Properties pane on the right, scroll down until you find Object Level Security.
4. Click the ellipsis (...) next to it. A new window will pop up, listing the roles you created ("Admin" and "Analyst").
5. By default, access is set to Default for both. Change the access level for the Analyst role to None from the dropdown menu.
6. Click OK.

AI Agents for Marketing

Crash Course

Graphed

Free PDF · the crash course

AI Agents for Marketing Crash Course

Learn how to deploy AI marketing agents across your go-to-market — the best tools, prompts, and workflows to turn your data into autonomous execution without writing code.

Download the PDF

Step 5: Apply the Changes and Test in Power BI

Once you’ve configured the security rules, you have to save them back to your Power BI model.

1. In Tabular Editor, click the Save icon (or press Ctrl + S). This pushes the changes from Tabular Editor back to your PBIX file.
2. Switch back to Power BI Desktop. You won't see any immediate changes.
3. To test your setup, go to the Modeling tab and click View as.
4. Check the box next to the Analyst role and click OK.

You will now see the report through the eyes of an analyst. Any visuals that used the Profit column will either be broken (showing an error) or will automatically adjust if they were designed to handle missing fields gracefully. More importantly, if you look at the Data view, you'll see the Profit column has vanished entirely from the Sales table. To see it again, simply click "Stop viewing" at the top of the report canvas.

Limitations and Best Practices

While OLS is fantastic, it's good to be aware of a few things:

• Reports Can Break: If a visual directly references a hidden column, that visual will error out. Plan your reports accordingly or create separate report pages for different roles.
• External Tool is an Annoying Additional Step for Admins: It heavily relies on Tabular Editor. You cannot set up or manage OLS within Power BI natively.
• Testing is Important: ALWAYS use the "View as" feature to double-check that each role sees exactly what you intended before you publish to the Power BI Service.
• Document Your Roles: As your security model grows, keeping a written record of which roles can see which objects will save you countless headaches down the line.

Final Thoughts

Object-Level Security is a must-have tool for any Power BI developer looking to build secure, scalable reports for diverse audiences. By allowing you to hide specific tables and columns, OLS helps protect sensitive data and streamline report views without the need for maintaining separate PBIX files for every user group.

The need to navigate external tools and manually configure roles for tables and columns truly highlights the friction involved in traditional business intelligence platforms. We believe that getting answers from your data shouldn't be so complicated. That’s why we built Graphed to be different. Instead of learning security rules and data modeling, you just connect your sources and ask questions in plain English - our AI data analyst handles the complexity of building real-time dashboards for you, turning hours of configuration into a 30-second conversation.