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.
