Utarbeidet med KI.
Row-level security, or RLS, allows the same report to display different rows to different users. A salesperson sees their own customers, a regional manager sees their region, and the management team sees everything. The alternative is to maintain separate reports for each department, and that workload only grows.
This guide shows how to configure it in the Power BI service. The same can be done in Power BI Desktop, but roles must still be assigned to users in the service.
Write down which roles exist and what each of them should be able to see. Should salespeople see only their own sales opportunities, or everyone’s on the team? Should a regional manager be able to see other regions for comparison purposes, or not at all? This is a business decision, not a technical one, and it should be made by the person who owns the figures.
RLS filters on a column in the model. If each user should only see their own rows, you need a column that links the row to the user, typically the salesperson's email address. If it is missing, it must first be added to the model, and it is worth taking care of that before proceeding.
Find the semantic model in the workspace, select More options, and then Open semantic model. The model opens in view mode, so switch to edit mode. Note that changes to the model are saved automatically and cannot be undone.
Select Manage roles on the ribbon, then select New. Enter a name for the role under Roles and press Enter. Use names that will make sense to those who will manage this later, such as Salesperson or Northern Regional Manager, rather than Role1.
Select the table the filter should apply to under Select tables, and define the rule under Filter data. The expression you enter must return true or false for each row. For a fixed restriction, the standard editor is sufficient.
If the rule needs to adapt to the user who is signed in, you must use DAX. Dynamic rules based on username or userprincipalname cannot be expressed in the standard editor. Select Switch to DAX editor and enter the rule there. This also allows you to use a single role instead of one role per person.
Select Save. The role now exists in the model, but no one has been assigned to it yet, so it currently has no effect.
Select Assign, add the users or security group that should have the role, and select Save. Use security groups from Entra ID rather than individual users wherever possible—this ensures that access is updated automatically when people change roles or leave.
Verify that the role provides the intended view, both that the correct rows are displayed and that no others are. Test at least one case per role, and pay particular attention to testing a user who should have limited visibility. Errors that grant excessive access are rarely detected by the user.
Document which roles exist, what they restrict, and who can approve changes. RLS is the part of a report that is easiest to overlook and most costly to get wrong, especially when the report is shared outside your own department.
Still et spørsmål eller del hva som hjalp deg.
Har du et spørsmål eller en erfaring å dele?
Bli den første som bidrar.
