OLS with Tabular Editor - Breaking visuals

[DaanRiefel]

Hi there,

I'm running into an issue with Object Level Security (OLS) applied via Tabular Editor, which causes certain table visuals to break — as expected — when a restricted user doesn't have access to a specific column.

About a month ago, I implemented a field parameter as a workaround. It worked perfectly: for users with restrictions, the column simply disappeared from both the data and the table visual, and everything functioned smoothly.

Now, trying the exact same setup again, it no longer works — the visual breaks when the user doesn't have access to one of the fields included in the field parameter. No changes were made to the roles or data model structure as far as I know.

Has anyone else experienced this behavior?
Is this a recent change in how Power BI handles OLS and field parameters?

My end goal is to have two roles:

• No Restrictions: full access to all columns.

• Restrictions: access to the same visual, but with one specific column hidden.

Blog OLS in combination with field parameters:

Chris Webb's BI Blog: Stopping Some Users Seeing Certain Columns Or Measures In Your Power BI Report...

Thanks in advance!
– Daan

[VahidDM · Accepted solution]

Power BI currently doesn’t support hiding columns secured by Object-Level Security inside a field-parameter definition. If you include a restricted column in your field parameter, the visual will error for that user, because the parameter still “sees” the column even though it’s hidden.

Workaround Options:

Calculation Group Instead of Field Parameter

Create a Calculation Group (via Tabular Editor) with one Calculation Item per column.

Each item returns the measure or column you want to show.

Secured users simply won’t see the Calculation Item that maps to the hidden column, and the visual won’t break.

Dynamic Measures / SWITCH Logic

Build a single measure that uses SWITCH( TRUE(), … ) to return each column’s value based on a slicer selection.

Don’t reference the physical column directly in the visual—only the measure. OLS will then remove the hidden column from the model, and your measure will automatically return blank or skip it.

Separate “View” Tables

Duplicate the base table in the model, remove the sensitive column from the duplicate, and apply OLS to that table only for restricted users.

Point your table visual to the duplicate when running as the restricted role.

[v-kpoloju-msft · Accepted solution]

Hi @DaanRiefel,

Thanks for reaching out to the Microsoft fabric community forum your clear and detailed explanation. Also, thanks to @VahidDM, for his inputs on this thread.

I understand that your setup with Object Level Security (OLS) via Tabular Editor previously worked where restricted users would not see a column in field parameter visuals, and visuals behaved gracefully.

However, based on recent changes in how Power BI handles OLS (especially when using field parameters), visuals may now break if any referenced column is inaccessible due to security settings. This is aligned with the updated behaviour of strict metadata enforcement under OLS.

Suggested Solution: To prevent visuals from breaking and restore the earlier experience:

• Create a mapping table that defines which roles have access to which field parameter columns.
• Use DAX to identify the current user's role (via USERNAME() or RLS).
• Filter the field parameter table dynamically based on allowed columns for that user.
• Use the filtered field parameter table in slicers or visuals this ensures only accessible columns are available and avoids visual failures.

This approach ensures that visuals only reference columns the user is permitted to see, avoiding OLS violations.

Kindly refer to the below mentioned links for better understanding:
Object-Level Security (OLS) with Power BI - Microsoft Fabric | Microsoft Learn
Analysis Services tabular model object-level security | Microsoft Learn

Hope this helps clarify things and let me know what you find after giving these steps a try happy to help you investigate this further.

Thank you for using the Microsoft Fabric Community Forum.

[v-kpoloju-msft]

Hi @DaanRiefel,

Just checking in to see if the issue has been resolved on your end. If the earlier suggestions helped, that’s great to hear! And if you’re still facing challenges, feel free to share more details happy to assist further.

Thank you.

[v-kpoloju-msft]

Hi @DaanRiefel,

Hope you had a chance to try out the solution shared earlier. Let us know if anything needs further clarification or if there's an update from your side always here to help.

Thank you.

[v-kpoloju-msft]

Hi @DaanRiefel,

Just wanted to follow up one last time. If the shared guidance worked for you, that’s wonderful hopefully it also helps others looking for similar answers. If there’s anything else you'd like to explore or clarify, don’t hesitate to reach out.

Thank you.

[VahidDM · Accepted solution]

Power BI currently doesn’t support hiding columns secured by Object-Level Security inside a field-parameter definition. If you include a restricted column in your field parameter, the visual will error for that user, because the parameter still “sees” the column even though it’s hidden.

Workaround Options:

Calculation Group Instead of Field Parameter

Create a Calculation Group (via Tabular Editor) with one Calculation Item per column.

Each item returns the measure or column you want to show.

Secured users simply won’t see the Calculation Item that maps to the hidden column, and the visual won’t break.

Dynamic Measures / SWITCH Logic

Build a single measure that uses SWITCH( TRUE(), … ) to return each column’s value based on a slicer selection.

Don’t reference the physical column directly in the visual—only the measure. OLS will then remove the hidden column from the model, and your measure will automatically return blank or skip it.

Separate “View” Tables

Duplicate the base table in the model, remove the sensitive column from the duplicate, and apply OLS to that table only for restricted users.

Point your table visual to the duplicate when running as the restricted role.