Row-level security explained for boards

Row-level security (RLS, security at row level) determines who may see which data within one shared database or report. Instead of building separate copies of a dashboard per customer or region, everyone looks at the same report, but each user automatically sees only the rows they are entitled to. For boards that want to share data with employees, partners or customers without losing control, this is the way to do that safely and at scale.

What is row-level security?

Row-level security is a security layer that governs access to data at the level of individual rows, not at the level of whole tables or reports. A sales manager then sees only the figures for their own region, while the board keeps the complete overview in that same report.

This differs from traditional access management (governing who may use which systems or files), which usually works at folder level or application level. RLS filters the data itself, based on who logs in. That makes one report usable for ten different audiences, without maintaining ten separate versions.

How do you set up row-level security in Fabric?

In Microsoft Fabric you set up RLS on the data model, not afterwards in separate reports. That way you prevent every new dashboard maker from having to set up the security again.

Work with a medallion architecture (a layered build from raw data to clean, usable data in three steps: Bronze, Silver, Gold) and build the security rules into the Silver or Gold layer. Link user roles to a central table with customer, region or department attributes. Then test with a few representative accounts whether everyone sees exactly the rows that belong to their role, before you roll a report out widely. Set this up from the first design, not as a later addition. That prevents a costly rebuild once the number of users grows.

Practical examples: sharing with partners and customers

RLS becomes truly valuable once you share data outside your own organisation. A multi-tenant environment (one system that serves multiple customers or partners at the same time, each with its own shielded data) asks for exactly that kind of filtering.

At Impacture that happens through the Sharing Engine: a layer that shares reports and AI outcomes with employees, partners and customers from the same Gold layer, with RLS as the underlying security. A logistics company can thus build one reporting environment in which each shipper only sees their own shipments, while the internal planning keeps the full overview. No separate environments per customer, no manual copying of figures.

Why row-level security contributes to governance

For boards, RLS is not only a technical measure, it is a governance instrument (the whole of rules and control around data management). It enforces that access is granted explicitly instead of implicitly via shared passwords or broad exports.

That fits the way many organisations have to deal with privacy legislation or customer contracts: data may only reach those who need it. RLS makes that demonstrable, because access is recorded in the model itself. Whether a specific setup also meets legal requirements such as GDPR depends on the full design, not on RLS alone.

Limitations and points of attention

RLS does not solve everything. It filters data based on predefined rules, so an unclear or outdated role structure still leads to the wrong access, even if the technology works correctly.

Complex role structures with many exceptions make a model slower and harder to maintain. Keep the number of rules manageable and document who has access and why. RLS also does not replace broader security such as login management (SSO) or network security. It is one layer in a larger whole.

Validating and managing roles

Roles that were once set up well often drift quietly as teams change. Therefore check periodically whether roles still match the current organisation.

Use separate DTAP environments (Development, Test, Acceptance, Production: a setup in which changes are tested first before they go live) to test new roles without risk to production data. Log who has which role and when it was last checked. That way row-level security remains an actively managed part of your platform, not a setting you switch on once and forget.

Row-level security makes one reporting environment safely usable for multiple audiences at the same time, from internal teams to external partners. Set up well from the medallion architecture, with clear roles and periodic checks, it prevents a tangle of separate reports and access rules. Want to know what this looks like for your organisation? Book a Discovery Call and discuss it in twenty minutes.