Row-level security (RLS) filters what a user sees when the report runs. Whether it also governs an export depends on where the filter is enforced and who produces the file. If the export runs under the recipient's identity and the filter is applied at query time, the file contains only that person's rows. Once the file is saved, though, nothing travels with it. It has no roles, no workspace permissions and no audit trail, so the control has to be applied before the file is created.
This guide covers both meanings of "RLS exports": exporting data from a report that has RLS, and exporting the RLS setup (roles and members) for an audit. It then covers how to automate recurring exports without widening anyone's access.
TL;DR
- RLS decides which rows a query returns. Exports inherit it when it is enforced at query time, including exports, extracts and APIs. Filtering only in the application layer can leak rows through exports and scheduled reports.
- A finished Power BI export file carries none of the model's RLS, workspace permissions or sensitivity-label enforcement. Control who can export and which identity generates the file.
- To export RLS roles and members for an audit, you query metadata (XMLA endpoint, Report Server database or REST API, or an audit tool). There is no single built-in CSV button for every tenant.
- Group-based assignments hide the individual users. Resolve them against Entra ID.
- For recurring exports, produce one file per recipient under their own security context and record who received what.
Table of Contents
- What row-level security does to a report
- How RLS works in Power BI
- What happens when someone exports
- How exports compare across platforms
- Exporting the RLS setup itself
- Automating exports without widening access
- Our perspective
- Automate secure exports with PBRS
- FAQ
- Sources
What row-level security does to a report
RLS is an access control that filters data at the row level based on a user's identity or role. A regional sales manager and a CFO open the same report and see different rows, because the filter is applied when the data is requested rather than when the page is drawn.
Where the filter lives matters a great deal for exports. When the database engine applies the filter predicate at query time, the result is independent of the front-end tool used. A correctly enforced policy then applies to direct queries, views, extracts and exports alike, because disallowed rows are excluded before results are returned.
The opposite design is the risky one. If you hide rows with a filter in the report layer only, anyone who can reach the data by another route, such as an API, an export or a scheduled job, can get the unfiltered set. That is the core of the export problem, and it is why "does RLS apply to exports?" has two honest answers: yes when enforced at the source, and no when it is only a visual filter.
How RLS works in Power BI
In Power BI, RLS is defined at the semantic model level using roles and DAX filter expressions and is enforced automatically for users with Viewer permissions in the workspace. You build roles in Power BI Desktop, publish the model, then assign users or groups to roles in the Service.
There are two styles:
- Static RLS. Each role holds a fixed filter, such as Region = "West". Simple, but you need a role per segment and the list grows.
- Dynamic RLS. One role uses DAX identity functions such as USERPRINCIPALNAME or USERNAME against a security mapping table, so the data filters to the authenticated user's identity. You maintain a table instead of dozens of roles.
One trap catches many teams. Users with Admin or Member workspace roles may bypass RLS. If the person building your export schedule or testing it holds one of those roles, they may see everything and conclude the security works when it has not been exercised at all. Test with an account that is only a Viewer, or with the role-impersonation view in Desktop.
For a deeper look at who should hold which workspace permission, see our guide to Power BI report access permissions.
What happens when someone exports
There are three export situations, and RLS behaves differently in each.
Interactive export by a user
A Viewer who exports visual data from the Service gets data that was already filtered by RLS for them. The risk is what happens next. The file is a plain CSV, XLSX or PDF. It has no RLS, no workspace permissions and no sensitivity-label enforcement, so it can be forwarded to anyone. The same source notes that the ExportReport activity can show who exported which report and when, which is the record you need to review.
The practical controls are upstream: limit who gets export rights, keep the exported columns to what the role needs, and review export activity regularly.
Programmatic export through the API
Export-to-file calls run as an identity you choose, and the result reflects that identity's access. That makes the choice of identity a security decision. If a service account with broad access generates a file and the file goes to a regional manager, RLS did not protect anything. Our comparison of the Export to File API and report automation explains the trade-offs, and the developer notes on one file per call show why per-recipient volumes need planning.
Scheduled and emailed reports
Native subscriptions send what the report looks like for a given user or a given configuration. Once you need hundreds of personalized files, the question becomes which security context each file was generated under. Application-layer filtering is the most exposed here: the Veritly guidance lists scheduled reports alongside exports and APIs as paths that can expose rows.
How exports compare across platforms
The same principle holds in every tool, but the mechanism differs. Use this as a checklist of where to look, not a substitute for each vendor's documentation.
| Platform | Where the row filter usually lives | What to check before exporting |
|---|---|---|
| Power BI | Roles and DAX filters on the semantic model | Which identity generates the file; Admin/Member bypass; export permissions |
| SSRS | Query parameters, or database-level security the report's data source passes through | Whether data source credentials are stored or per-user; whether parameters are the only filter |
| Tableau | User filters, data source filters or database-level security | Whether the extract or live connection carries the filter; who owns the schedule |
| Database (SQL Server, Databricks and others) | Policy applied by the engine | Whether every tool and service account goes through the policy |
The most robust pattern is the last row: when the database enforces the policy, every export path inherits it. If you are weighing platforms and how each handles governance, this overview of Power BI and Tableau compared is a reasonable starting point.
Exporting the RLS setup itself
A second reading of the keyword: you want a list of roles and the people in them, for a review or an access recertification. Be aware of what is and is not available.
- Premium or Premium Per User semantic models. Role definitions and memberships can be read through the XMLA endpoint. One walkthrough uses a template that queries the model this way and saves the result to CSV. It notes that the endpoint is available only on Premium or Premium Per User, and that the person running the query needs admin permissions on the dataset.
- Power BI Report Server. Assignments can be queried from its database or REST API, then written out to Excel or CSV by whatever tool you already use.
- Third-party audit tools. Some can produce an RLS inventory as Excel or JSON.
The sources do not describe one universal Microsoft CSV export covering all tenants, so plan on one of the routes above and confirm the permissions and capacity you need in your own environment.
The group membership blind spot
If you assign an Entra ID security group to a role, the export shows the group, not the people. Group membership is managed in Entra ID and is not exposed through Power BI RLS APIs, so you have to correlate it with directory data yourself. Plan this step before an audit rather than during it.
What a useful RLS audit records
A solid review should inventory all static and dynamic roles, trace identity propagation (UPNs, aliases, guest identities) and check for overlapping roles that might broaden access. The same discipline applies to any access-control review; this piece on role assignments and access control shows how the same questions look in a CRM, which is useful if you are building one review template for several systems.
A simple audit sheet has these columns:
- Report or semantic model
- Role name and filter logic (static or dynamic)
- Assigned user or group, and the resolved members
- Workspace role of each member (Viewer, Member, Admin)
- Export rights and the date of the last review
- Whether the person is internal, a guest or an external recipient
Automating exports without widening access
Manual exports do not scale and they are hard to audit. Automated ones are easier to govern if you design them around the security context. A workable checklist:
- Decide the identity per file. Each recipient's file should be generated under that recipient's access, or filtered by a rule derived from it, never by a broad service account that then fans out the result.
- Test as a Viewer. Admin and Member roles can bypass RLS, so a passing test from those accounts proves little.
- Handle guests and external recipients explicitly. Include them in the identity trace so aliases and guest accounts map to the right role.
- Watch for overlapping roles. A user in two roles can see the union of both. Check this before a schedule goes live.
- Pick the format on purpose. PDF is harder to repurpose than Excel or CSV, but a recipient who needs analysis will need the data. Match format to need.
- Log deliveries. Record recipient, report, parameters and time, so a later audit can answer "who got what".
- Re-run the review on a schedule. Roles drift as people change jobs.
For the mechanics of building these schedules, our tutorials on flexible scheduling of Power BI exports and scheduled reports to Excel walk through the setup, and three secure export methods that preserve Power BI RLS covers approaches for BI admins.
Our perspective
We see the same pattern in organizations that outgrow native scheduling. The RLS design is fine. The export path is the weak point, because a file is generated under one identity and delivered to many people.
Our view is that report delivery should be treated as part of your security model, not a separate chore. That means personalized output per recipient, data-driven schedules that follow your security mapping, and a record of every delivery. It also means doing it without a thicket of custom scripts or fragile workflows that nobody wants to own.
This is what PBRS, ATRS and CRD are designed for: scheduling, personalizing, exporting and delivering reports from Power BI, SSRS, Tableau and Crystal Reports to licensed or external recipients, on infrastructure you control. Because it runs on-premises and the company holds SOC 2 Type II certification, security and IT teams have something concrete to review during their own governance process.
Christian Ofori-Boateng
Automate secure exports with PBRS
If your team spends hours each week exporting dashboards to PDF, Excel or email, or you have outgrown native subscriptions, PBRS for Power BI and SSRS is built to schedule, personalize, export and deliver Power BI reports to the right person, in the right format, on time. Event-triggered and data-driven schedules let your delivery follow the same logic as your security mapping. Tableau and Crystal Reports teams have ATRS and CRD with the same approach.
You can see how it works without Power Automate flows or custom scripting on the automated exports page, or start from the ChristianSteven home page to choose the product for your BI platform. Subscription and perpetual licenses are both available.
FAQ
Does row-level security apply when a user exports to Excel or CSV?
The export contains only the rows the user was allowed to see, provided RLS is enforced at query time. The file itself then has no RLS, so anyone it is forwarded to can read it. Control export rights and review export activity.
Can I export a list of Power BI RLS roles and members to CSV?
There is no single built-in export for every tenant. On Premium or Premium Per User models you can query role metadata through the XMLA endpoint and save it to CSV. Report Server assignments can be queried from its database or REST API.
Why does my RLS audit show groups instead of people?
Group membership lives in Entra ID, and Power BI RLS APIs do not expose it. Pull the membership from your directory and match it to the role assignments to see the actual users.
Why did my RLS test show all the data?
Users with Admin or Member workspace roles may bypass RLS. Test with a Viewer account or use the role-view feature in Power BI Desktop.
How do I send a different export to each recipient?
Use a scheduling tool that generates one file per recipient from a data-driven list, under each recipient's own access. Keep a delivery log so every file can be traced.
Sources
- Row-Level Security in Practice, Veritly
- What is Row-Level Security? Databricks Blog
- Power BI Row-Level Security: Roles, DAX & Limits, Embeddable
- Power BI Row-Level Security (RLS): A Comprehensive Tutorial, DataCamp
- Report data exports (ExportReport activity), Measure Killer
- Row-level security (RLS): roles, filters & members, Measure Killer
- How to get Power BI RLS role users and export to CSV, FourMoo
- Exporting Power BI Row-Level Security Details, Curated SQL
- AI Power BI RLS, Permission and External Sharing Security, Datrick
- Power BI vs Tableau
- Behörighetsstyrning i CRM