{"id":26398,"date":"2024-11-15T14:26:00","date_gmt":"2024-11-15T13:26:00","guid":{"rendered":"https:\/\/alistar.net\/?p=26398"},"modified":"2026-10-02T10:52:44","modified_gmt":"2026-10-02T08:52:44","slug":"row-level-security-and-security-filtering-behavior","status":"publish","type":"post","link":"https:\/\/alistar.net\/en\/blog\/row-level-security-en-security-filtering-behavior\/","title":{"rendered":"Row-level security and security filtering behavior"},"content":{"rendered":"

With row-level security, data-based filtering can easily be added to a semantic model. By using the logged-in user\u2019s username, this can also be made dynamic. Of course, much has already been written about this. Recently, however, I was asked to configure the security so that users at a higher level could always view all data, but at the detailed level, only the information pertaining to their own team or department. To clarify: At the top-level, users should be able to view all revenue, but at the detailed level, only customers in the Netherlands. <\/p>\n\n\n\n

What is RLS?<\/h2>\n\n\n\n

Role-based security involves filtering data based on specific security rules. This is often implemented in Power BI by defining different roles. Data can then be filtered within these roles. Users are only allowed to view data from a specific company, a specific country, or a specific business unit. By making this security dependent on the user, maintenance and the number of roles can be significantly reduced. <\/p>\n\n\n\n

Security Filtering Behavior<\/h2>\n\n\n\n

The way the model interprets security can be influenced by the \u201csecurity filtering behavior\u201d setting. This setting can be configured on a per-relationship basis. This can be automated using scripting, if desired. There are three basic settings available: <\/p>\n\n\n\n