OLS with Tabular Editor - Breaking visuals

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.

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.