Row-Level Security & Access Control
Implement row-level security (RLS) to control who sees which data, assign workspace roles, configure item-level and semantic model access, and manage RLS group membership.
Controlling who sees what
Think of a hotel with different room keys. Everyone can enter the lobby (the report). But only North Region managers can open the North Region data room, and only South Region managers can open theirs. Same building, different access.
Row-Level Security (RLS) filters data rows based on who’s viewing the report. A regional manager sees only their region’s data. A department head sees only their department. The report is the same — but the data is different for each viewer.
Workspace roles
| Role | Can View | Can Edit/Publish | Can Share | Can Manage |
|---|---|---|---|---|
| Viewer | ✓ | ✗ | ✗ | ✗ |
| Contributor | ✓ | ✓ | ✗ | ✗ |
| Member | ✓ | ✓ | ✓ | ✗ |
| Admin | ✓ | ✓ | ✓ | ✓ (add/remove users, delete workspace) |
Riley at Coastal Fresh (🛒) assigns roles:
- Admin: Herself and the BI team lead
- Member: Department heads (can share reports with their teams)
- Contributor: Data analysts who build new reports
- Viewer: Store managers and regional managers who consume dashboards (RLS applies to Viewers)
Important: RLS only restricts users with the Viewer role. Admin, Member, and Contributor bypass RLS entirely. If you need RLS to apply to someone, they must be a Viewer — or consume content through an app.
Item-level and semantic model access
Item-level access grants permissions on individual reports or dashboards without giving workspace access:
- Share a single report with a specific person
- They see the report but not other workspace content
Semantic model access (Build permission) allows others to create new reports using your published dataset:
- Build permission → user can create their own reports on top of your model
- Without Build permission → user can view reports but can’t build new ones
Dr. Ethan at Bayview Medical (🏥) grants Build permission on the patient dataset to the quality team — they can build their own reports without accessing the clinical dashboard workspace.
Row-Level Security (RLS)
Step 1: Define roles in Power BI Desktop
Modeling → Manage roles → New role
Each role has a name and one or more DAX filter expressions on tables.
Example: Riley creates a role for each region:
North Region role:
[Region] = "North"South Region role:
[Region] = "South"Dynamic RLS uses the user’s identity instead of hardcoding values:
[ManagerEmail] = USERPRINCIPALNAME()This filters the data to rows where the ManagerEmail column matches the logged-in user’s email. One role, works for everyone.
Step 2: Test roles in Desktop
Modeling → View as → select a role to preview what that user sees. Always test before publishing.
Step 3: Assign membership in the Power BI service
After publishing, go to the semantic model → Security → select the role → add users or security groups.
Kenji at Apex Manufacturing (🏭) uses dynamic RLS: each factory manager’s email is in the FactoryManager column. He creates one role with [FactoryManager] = USERPRINCIPALNAME() and adds all managers to that role. Each manager sees only their factory’s data.
Exam tip: static vs dynamic RLS
Static RLS: Hardcoded filter values per role. Requires separate roles for each group.
Role: "North" → [Region] = "North"
Role: "South" → [Region] = "South"Dynamic RLS: Uses USERPRINCIPALNAME() or USERNAME() to filter based on the logged-in user. One role handles everyone.
Role: "RegionManager" → [ManagerEmail] = USERPRINCIPALNAME()The exam strongly tests dynamic RLS. Look for scenarios with a mapping table that connects user emails to data access permissions.
RLS with security groups
Instead of adding individual users to RLS roles, use Azure AD (Entra) security groups:
- Create a security group:
SG-PowerBI-NorthRegion - Add North region managers to the group
- Assign the group to the “North Region” RLS role
This scales much better — when a new manager joins, add them to the group instead of modifying Power BI settings.
| Feature | Individual Users | Security Groups |
|---|---|---|
| Management | Add/remove each person manually | Manage membership in Entra — automatic in Power BI |
| Scale | Difficult at 50+ users | Handles thousands easily |
| Best practice | Development/testing only | Always use for production |
Knowledge check
Kenji has 12 factory managers, each managing one factory. He wants each manager to see only their factory's data. What's the most scalable approach?
Dr. Ethan wants to grant the quality team the ability to create their own reports using the patient dataset — but not access the clinical dashboard workspace. What should he configure?
🎬 Video coming soon
Next up: Sensitivity Labels and Governance — protect your data with Microsoft Purview integration.