Row-level security (RLS) is the BI access control mechanism that filters the data visible to a report consumer at query time — based on the user’s identity or role — so that different users querying the same report see different subsets of the data. In a finance BI context, RLS enforces the boundary between what different finance users are authorised to see: the Saudi entity’s finance team sees only Saudi entity data; the group CFO sees all entities; the OPEX budget owner for the UAE sees only their cost centres. RLS achieves this through a single shared data model and report rather than through separate reports or separate datasets for each user population — which is the alternative approach that RLS replaces and that becomes operationally unmanageable at scale.
How It Works
RLS is implemented at the semantic model or BI platform layer, not in the underlying data warehouse. In Power BI, RLS is configured on the dataset as a role definition — a DAX filter expression that restricts which rows of a dimension table (and by extension, which fact rows through relationships) are visible to users assigned to that role. The filter expression references the current user’s identity (USERPRINCIPALNAME()) or a role assignment, matched against a security mapping table that defines which dimension members each user or role can access. In Oracle Analytics Cloud, data-level security is implemented through data filters on subject areas, with row-level filtering based on user session attributes. In Tableau, RLS uses user filters mapped to a security data source.
Design Decisions and Trade-offs
The security mapping table design is the central governance decision in an RLS implementation. Two patterns are common:
- Static role assignment: Each role is defined in the BI platform with a fixed filter expression. Adding new users to a role grants them the defined data access. Simple to manage but inflexible for environments where access boundaries change frequently.
- Dynamic security mapping table: A table in the data warehouse maps each user’s identity to the dimension members they can access. The BI model’s RLS filter joins the current user’s identity to this mapping table at query time. Flexible — access changes are made by updating the mapping table, not by modifying BI platform role definitions. Adds a join to every query that RLS applies to.
The dynamic mapping table approach is recommended for finance BI environments with frequent access changes — entity restructuring, role changes, new joiners in subsidiary finance teams — where maintaining static role definitions in the BI platform becomes an operational burden.
Common Implementation Errors
The most damaging RLS implementation error is applying security only to the fact table without applying it to all dimension tables that a user could use to traverse to restricted data. When RLS filters the Entity dimension to show only UAE entities for a UAE finance user, but the Cost Centre dimension is not filtered, the UAE user can create a report filtered on UAE cost centres that includes cost centre members belonging to Saudi entities — dimension members that should be invisible to them. RLS in a relational model must be applied comprehensively across all dimensions whose members carry access implications, not only on the primary dimension used to define entity-level access boundaries.
How Loop Wise Solutions Designs for This
We document the full RLS requirement — which user populations exist, which dimension members each population can access, and which dimensions carry access implications — before configuring any security in the BI platform. We test RLS by impersonating each user role in the BI platform’s test mode and verifying that restricted dimension members and their associated fact data are fully invisible, not merely filtered from the primary entity dimension while remaining accessible through secondary dimension traversal.
Answers before you ask.
Which rows of data a report user can see, based on their identity, role, or group membership — without needing separate report versions or data models per audience. One report and one model serve everyone, but each user sees only the rows they are permitted, such as their own entities or cost centres.
Because in a group, different users must see only their own entities or cost centres from the same shared model. Building separate reports per entity is unmanageable; RLS filters the single model by user instead. It delivers per-user data restriction at scale, which is exactly what multi-entity finance reporting requires.
By applying a security filter tied to the user at query time, so the same report returns only that user's permitted rows. Without RLS, restricting access would mean cloning reports or datasets per audience — a maintenance burden that multiplies with every entity. RLS keeps one governed model and report while enforcing per-user data boundaries.
Misconfigured rules that either expose data a user should not see or block data they need. Because RLS filters silently, errors are not obvious until someone sees the wrong rows. Thorough testing per role, and mapping users to their permitted data correctly, are essential — a subtle rule error can leak sensitive entity data across a group.