Object-level security

What it does

Hides whole tables or columns from a role, including their names and metadata. For a viewer without permission, the secured object doesn't exist — not greyed out, not empty, absent.

Key facts

OLS is defined inside model roles, the same roles that carry RLS filters. One role can do both.
You can't create OLS definitions natively in Power BI Desktop. You create the roles in Desktop, then set table permissions with an external tool — Tabular Editor is the one Microsoft names.
Permissions are set per table or column to None (hidden, OLS enforced) or Read (visible).
Like RLS, OLS only applies to workspace Viewers. Admin, Member and Contributor have edit permission and are unaffected.
Models with OLS configured aren't supported with Quick insights visualisations, Smart narrative visualisations, or the Excel Data Types gallery.
Users without permission get a "field can't be found" error on every visual that uses the secured field.
Role membership is assigned in the service on the semantic model's Security page, exactly as for RLS.

When to use / skip

Use OLS when a column is the sensitive thing rather than the rows — salary, national insurance number, cost price, patient identifiers — and when you can't reasonably split the model. Skip it when the answer is simply "don't import that column", which is very often the right answer and costs nothing to maintain. Also skip it when the audiences are truly separate: two models with two column sets is easier to explain, easier to test and doesn't need a third-party tool in the build pipeline. OLS is the answer to "same model, same rows, different columns", which is a narrower requirement than people expect.

Configuration decisions

Whether the requirement is genuinely OLS or is actually "leave the column out" or "split the model".
Which external tool goes into the build process, and whether the client's change control will accept it.
How OLS roles and RLS roles are combined — one role doing both, or separate roles that users hold together.
Which reports are allowed to use secured fields, given that any visual referencing one breaks for restricted users.
Whether losing Quick insights, Smart narrative and the Excel Data Types gallery on this model is acceptable.

Gotchas

OLS and RLS live in the same roles and stack additively with each other's role membership. A user in two roles gets the union of visible objects and the union of visible rows, which may be more than either role's designer intended.
Reports break rather than degrade. A restricted user opening a page containing a secured column sees error tiles, so you need separate report pages or separate reports per audience — that's the real cost of OLS.
The whole thing depends on an external tool that isn't part of Power BI. If the person who owns Tabular Editor leaves, so does the ability to change the security model.
Measures that reference a secured column will also fail for restricted users, even if the measure output looks harmless.
Nothing in the Desktop UI tells you OLS exists on the model. It's invisible until you open the model in a tool that shows table permissions.

Consultant notes

Ask "can we just not bring the column in?" before designing anything. It resolves a genuine majority of stated OLS requirements.
If OLS is going ahead, plan the report layer at the same time. The security model is the easy half; producing report pages that work for every combination of roles is the work.
Get the external tool approved by the client's IT before you build with it. Finding out in month three that Tabular Editor can't be installed on the build agent is a bad week.
Document the OLS configuration outside the model file. It's not visible in Desktop, and the next consultant will not find it by accident.

Worth another look if native OLS authoring lands in Power BI Desktop.