What is Object Level Security in Power BI?
Object-Level Security (OLS) is a powerful data governance feature in Power BI that allows you to hide entire tables or columns from specific user groups. This guide will walk you through what OLS is, why it's so useful, and how you can implement it-step-by-step to create more secure and streamlined reports.
What Exactly is Object-Level Security?
At its core, Object-Level Security (OLS) lets you control the visibility of your data model's "objects" - specifically, tables and columns. While most Power BI users are familiar with Row-Level Security (RLS), which filters the rows of data a user can see, OLS takes security a step further by hiding a table or column altogether.
Think of it like this:
- Row-Level Security (RLS) is like telling a sales manager, "You can see the SalesData table, but you'll only see the rows for the Pacific Northwest region." The table structure is visible, but the data within it is filtered.
- Object-Level Security (OLS) is like telling a salesperson, "You can't even see that the AdminSalaries table or the ProfitMargin column exists in our data model." It doesn't appear in their field list, so they can't reference it, query it, or even know it's there.
This allows you to build a single, unified data model and report that serves different audiences, simplifying development and maintenance. A finance user sees all financial columns, while a sales user sees only the sales-related columns, all from the same published report.
Why Should You Use OLS in Power BI?
Implementing OLS might seem like extra work, but it offers significant benefits, especially in organizations with diverse user groups and sensitive data.
Enhanced Data Security
The most obvious benefit is an extra layer of security. You can hide tables or columns containing personally identifiable information (PII), executive salaries, profit margins, or any other proprietary data from users who don't need access. This prevents accidental exposure and helps lock down critical business information within a more manageable framework.
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.
Simplified Report and Model Management
Without OLS, the common workaround for differing data access needs was to create multiple versions of the same report. You might have "Sales Report - For Executives" (with profit margins) and "Sales Report - For Regional Reps" (without profit margins). Over time, this becomes a maintenance headache. OLS lets you consolidate this effort into a single data model and report, applying different security "views" on top of it. Updating a measure or visual only needs to happen in one place, not across multiple files.
An Improved and Cleaner User Experience
A data model can quickly become cluttered with dozens of tables and hundreds of columns. For users who only need a small subset of that data, navigating this complex field list can be intimidating and confusing. OLS declutters their experience by showing them only the tables and columns relevant to their role. This makes self-service analytics more intuitive and reduces the chance of users creating visualizations with inaccurate or irrelevant data.
Fulfill Compliance Requirements
For businesses subject to regulations like GDPR, HIPAA, or CCPA, OLS is an essential tool for compliance. It provides a concrete method for restricting access to protected data categories, ensuring that only authorized personnel can view sensitive personal or health information. This is a crucial aspect of responsible data governance.
How to Set Up Object-Level Security: A Step-by-Step Guide
Unlike Row-Level Security, OLS cannot be configured directly inside the Power BI Desktop interface. You'll need to use an external tool, and the most common and effective one is Tabular Editor.
Note: OLS is a Power BI Premium or Premium-Per-User (PPU) feature. It will not work in a Pro-only workspace.
Step 1: Get Tabular Editor
Tabular Editor is a lightweight, open-source tool that allows you to directly manipulate Analysis Services Tabular Models, which is what powers Power BI datasets. If you don't already have it, you can download it from their website. Install either version (Tabular Editor 2 or 3) on your machine. Once installed, it will automatically appear in the External Tools ribbon inside Power BI Desktop.
Step 2: Create Roles in Power BI Desktop
Before moving to Tabular Editor, it's best to create your security roles within Power BI Desktop - the same way you would for RLS. This makes them easier to manage down the line.
- In Power BI Desktop, go to the Modeling tab.
- Click on Manage Roles.
- Click Create to add new roles. For this example, let's create two roles:
- Don't apply any RLS filters for now. Just create the empty roles and click Save.
Step 3: Launch Tabular Editor and Connect to Your Model
Now, let's implement the OLS rules.
- Go to the External Tools tab in Power BI Desktop.
- Click on the Tabular Editor button. This will launch the tool and automatically load your current data model.
The Tabular Editor interface shows all the components of your data model in a tree view on the left, including tables, columns, measures, and the roles you just created.
Step 4: Hide a Column with Object-Level Security
Let's configure our Sales_Rep role to hide a sensitive column in the "Financials" table called Profit.
- In Tabular Editor's model tree on the left, expand the Roles folder. You should see your
Finance_AdminandSales_Reproles. - Select the
Sales_Reprole. In the properties pane (you may also need to navigate in the tree), you will see an Object Level Security section or property. - By default, OLS is set to 'Default' for everything. We need to override this for the specific objects we want a role to be able to access or NOT access. To create a more refined view of OLS for our roles, we can instead: In the model tree, expand Tables > Financials > Columns.
- Click on the
Profitcolumn. - In the property grid on the right, find the Object Level Security property and expand it. It will list all the roles in your model.
- Find the
Sales_Reprole in the list and change its value from Default to None.
This setting explicitly tells Power BI to hide the Profit column from any user who is a member of the Sales_Rep role. For the Finance_Admin roles, leave the value as Default, which means they will be able to see it.
Tip: You can do the same for hiding an entire table. Just click on a table name, navigate to its Object-level Security settings, and set the corresponding Role to None.
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.
Step 5: Save and Publish to the Power BI Service
- In Tabular Editor, click the Save icon (or hotkey Ctrl + S). You will see a small window listing the modifications you've made. Confirm them. This writes the OLS metadata back into your local .pbix file. No separate file is created, it modifies the model within Power BI desktop.
- Close Tabular Editor and go back to Power BI Desktop. Save your .pbix file one last time.
- Publish your report to a workspace that has a Power BI Premium capacity.
- In the Power BI service, navigate to the dataset, click the ellipsis (...) and select Security.
- Here, you will see the roles you created. Assign users or user groups from Azure Active Directory to the appropriate roles. For example, add your sales team user groups to the
Sales_Reprole.
Step 6: Test Your Roles
It's absolutely essential to test your security configuration. Staying in the Security section in the Power BI Service, click the ellipsis (...) next to a role (e.g., Sales_Rep) and select Test as role.
Power BI will now render the report as if you were a member of that role. Check your field lists, and you'll see that the Profit Column is missing from the Financials table. This means OLS is working!
Important Considerations and Limitations
While OLS is powerful, there are a few pitfalls you'll want to avoid while working with a more complex report/dataset deployment:
- Broken Measures and Visuals: If a user is part of a role that hides a specific column or table, any measure or visualization that references that objects will fail to load or be rendered. Always test with the "test as role" feature to ensure everything works correctly.
- Exported Data: When a restrictive user exports or analyzes data in Excel, their security constraints are still honored: hidden objects simply don't appear in the underlying data they connect to. However, a user may see those objects if another user shares a raw set of data from Excel.
- Dynamic OLS/RLS Rules & Logic: Using OLS with any dynamic or complex rules and logic has additional complexity, but both RLS/OLS rules and logic will still be honored. It's recommended that users are assigned only one OLS/RLS role per user or group to avoid conflict.
Final Thoughts
In summary, Object-Level Security is an essential tool for creating a secure, elegant, and maintainable analytics environment in Power BI. It moves beyond filtering data by allowing you to completely hide tables and columns, simplifying your report designs while simultaneously locking down your sensitive data so that the correct users are only seeing the data and insights you want them to see for their specific role.
Of course, managing this level of complexity isn’t for everyone. For marketing and sales teams overwhelmed by managing security roles or juggling multiple report versions, there’s an easier way to get insights. At Graphed, we bypass this setup complexity entirely. By connecting directly to sources like Google Analytics, HubSpot, and Salesforce, you get live insights that allow you to just ask “show me US sales pipeline performance this quarter” and instantly build the dashboards in minutes, whereas this would take hours within Power BI.
Related Articles
How to Create Facebook Ads API for Claude Code
Create a Meta Marketing API access token that never expires, using a system user, so Claude Code can pull Facebook ad reports and manage campaigns.
ClickHouse vs Postgres: When to Switch to Columnar
Comparing ClickHouse vs PostgreSQL means matching storage architecture to workload. Row storage wins for transactions. Columnar wins for scan-heavy analytics.
Google Ads for Orthodontists: Get More Booked Consults
Most orthodontic Google Ads campaigns waste money on low-intent searches. The problem is structure, not the platform.