{"id":10659,"date":"2023-02-22T09:03:41","date_gmt":"2023-02-22T08:03:41","guid":{"rendered":"https:\/\/www.abd.es\/?p=22068"},"modified":"2024-08-28T14:48:18","modified_gmt":"2024-08-28T12:48:18","slug":"seguridad-a-nivel-de-fila-en-power-bi","status":"publish","type":"post","link":"https:\/\/www.abd.es\/en\/2023\/02\/seguridad-a-nivel-de-fila-en-power-bi\/","title":{"rendered":"Row-Level Security in Power BI"},"content":{"rendered":"

\"\"Once we grant access to a Power BI<\/a> report to various users in the organization, we might consider that users shouldn't have access to all the information, but only to part of it\u2014their own part. That is, the information should be filtered to show and calculate only based on the records belonging to the user. This is a common scenario in most companies where data access security plays an important role.<\/p>\n

Similarly, another scenario could be that, for example, in a Power BI sales report, we want each branch to access only its own data. We can divide the organization into sales areas and create a role for each area; from there, it would simply be a matter of assigning the user to the corresponding role.<\/p>\n

This is when we talk about Row-Level Security, which is established by creating roles in Power BI Desktop. In the role, a DAX-formulated condition is set, such as Area Code = \"Area\" or, similarly, if any of the data model's tables contains a field with the email or user used to validate the user, we can associate it with the expression\u00a0 userprincipalname().<\/em><\/strong><\/p>\n

We see it in the following steps in an example where our analysis will be performed on a Business Central Absence Registration table, and we want each user to see only their absences and only those of the Vacation type:<\/p>\n