RLS, OLS, and Workspace Roles Protect Different Things
Security in Fabric and Power BI becomes confusing when several controls are treated as interchangeable. Row-level security, object-level security, and workspace roles all influence what a person can do, but they operate at different layers and answer different questions.
For DP-600, that distinction matters because a model can be correctly configured for one control and still expose more than intended through another access path. A Fabric Analytics Engineer Associate needs to reason about both content permissions and data permissions.
The durable mental model is simple: workspace roles govern what users can do with workspace content, RLS filters which rows a model role can see, and OLS hides selected tables or columns from a model role. The complications begin when edit permissions, Build access, Direct Lake behavior, or downstream sharing are added.
Workspace roles are about the workspace and its items
Fabric workspaces commonly use Admin, Member, Contributor, and Viewer roles. These roles determine capabilities such as creating, editing, publishing, sharing, or viewing content. They are not merely another form of row filtering.
A user who can edit a semantic model is in a different security position from a pure consumer. Microsoft documents that RLS and OLS are intended to constrain Viewers; users with Admin, Member, or Contributor access have edit-level capabilities that bypass those model-role restrictions.
That is why assigning a powerful workspace role and then expecting RLS to behave as the primary barrier is a design mistake.
RLS filters rows inside the semantic model
Row-level security applies filter logic to model tables. A regional sales role might see only rows for assigned regions; a manager role might resolve an organizational mapping dynamically from the signed-in identity.
The model still contains the same columns and measures. RLS changes which rows participate in the user’s queries. This is appropriate when different consumers need the same analytical structure but are entitled to different subsets of the data.
RLS should be tested with realistic role membership and filter paths. A rule on the wrong side of a relationship, an ambiguous filter direction, or an incomplete mapping table can produce results that look plausible while exposing the wrong slice.
OLS hides model objects rather than filtering their rows
Object-level security is used when a user should not discover or query a table or column at all. A sensitive salary column or internal margin field can be hidden from a role so the secured object behaves as though it does not exist.
That is fundamentally different from RLS. If the concern is ‘this audience can see customer rows but must not see the National ID column,’ a row filter does not solve the requirement. OLS addresses the object itself.
This layered approach is consistent with broader data security practice: access design should distinguish between who can reach a system, which records they can read, and which sensitive attributes they are allowed to discover.
RLS and OLS are not substitutes for correct workspace assignment
Model security is strongest when consumers are given the least workspace privilege required for their task. A Viewer who receives access through an app or report can remain subject to model roles, while a contributor-level user is expected to work with the content itself.
That aligns with the logic of identity and access management: privilege should follow job responsibility, and elevated authoring access should not be granted simply to make sharing convenient.
If a business consumer needs to build reports from a governed model, evaluate Build permission and the model’s security behavior rather than promoting the person to a workspace role that provides broader edit access.
Permissions can be inherited through several sharing paths
A user might gain access through a workspace, an app, a directly shared report, a semantic-model permission, or another artifact that depends on the model. Security reviews therefore need to trace effective access, not only the role shown on one screen.
Build permission is especially important because it enables additional ways to query a semantic model, such as creating reports or using connected tools. If RLS is defined and the user has only read or Build permission, role membership still matters; write permission changes the security relationship.
Document the intended consumption path so administrators can distinguish legitimate inherited access from accidental privilege.
Direct Lake does not remove semantic-model security
Direct Lake changes how a semantic model accesses data in OneLake, but users still interact with model relationships, measures, and security rules. RLS can be used on Direct Lake semantic models.
Performance behavior can differ if a model uses a mode that can fall back to DirectQuery, but the security requirement does not disappear. A query should never become unrestricted merely because the execution path changed.
Security testing belongs in performance testing as well. A report that is fast as an owner but slow for secured users may be exercising different filter logic or query paths.
Security rules are part of the model’s business design
Dynamic RLS often depends on organizational tables: user-to-region, manager-to-team, customer-to-tenant, or partner-to-account mappings. Those mappings are business data and need the same quality controls as facts and dimensions.
A broken entitlement mapping is a data quality defect with security consequences. Stale employee assignments can overexpose data; duplicate mappings can expand access unexpectedly; missing mappings can deny valid access.
Treat entitlement tables as governed assets with owners, refresh expectations, and validation checks instead of embedding unmanaged email lists directly inside DAX rules.
Governance needs evidence, not just configuration
Security configuration can drift as people change roles, workspaces are copied, apps are republished, or models are redeployed. A one-time review is not enough for high-value analytical data.
An effective information-security governance process records who owns each workspace and model, which audiences are allowed, how role membership is maintained, and how exceptions are approved.
Test representative users after major deployments. Review elevated workspace memberships. Validate that sensitive objects remain hidden and that row filters still produce the intended scope.
Choose the control that matches the question
Ask three separate questions during design. First: what can this person do to the Fabric item or workspace? Second: which records may the person query? Third: which model objects may the person discover or use?
Workspace roles answer the first question, RLS the second, and OLS the third. Additional controls such as item permissions, OneLake security, SQL permissions, sensitivity labels, and tenant settings may add further layers.
The architecture becomes easier to reason about when each requirement is assigned to the layer that actually enforces it rather than stacking controls without a clear threat model.
Static and dynamic RLS have different operational risks. Static roles can be simple to understand but become hard to maintain when many regions or departments need separate memberships. Dynamic RLS centralizes logic around identity mappings, but the entitlement table becomes critical infrastructure. Test user principal formats, duplicate identities, inactive employees, and cases where one person legitimately belongs to multiple business scopes.
Security can also fail through aggregation and metadata, not only raw rows. A user who cannot see individual records may still infer sensitive information from totals if groups are too small. OLS can hide columns, but it does not automatically solve inference risk. For regulated or sensitive domains, combine model security with appropriate aggregation, masking, or source-layer controls where the business requirement demands them.
Service principals, embedded scenarios, and automated processes require separate review because the effective identity may differ from an interactive user’s identity. A security design that relies on USERPRINCIPALNAME() for human viewers should be validated carefully if reports are later embedded or accessed through automated tooling. Authentication context is part of the data-security contract.
Document role intent in business language. A role named RLS_Region_04 tells a future administrator very little, while ‘Regional Sales Manager — assigned territories only’ captures the purpose. Include the source of membership and the owner who approves access. Technical rules are easier to maintain when the business entitlement is explicit.
Finally, test denial as deliberately as allowance. Security QA should verify that authorized users see what they should and unauthorized users cannot discover what they should not. Negative tests catch overly broad relationships, forgotten workspace privileges, and objects that remain visible through an unexpected sharing path.
Review security whenever workspace topology changes. Moving an item, creating a new app, copying a workspace, or introducing another semantic model can change how users reach the data even when the original RLS and OLS definitions stay untouched. Access paths are part of the design, so topology changes deserve the same security review as rule changes.
Keep privileged support access time-bounded where practical. Troubleshooting sometimes requires Member or Contributor rights, but permanent elevation for convenience undermines the security model. A clean operating process can grant temporary elevated access, record why it was needed, and return the person to a consumer role when the task is complete.
RLS, OLS, and workspace roles are complementary because they protect different surfaces.
The safest design gives consumers only the workspace privilege they need, uses model roles for data-level restrictions, and verifies effective access through the same path real users will take. Security is correct only when the combined result matches the business entitlement.