Row-level security
Row-level security lets you share one report with many people and have each of them
see only their own rows: their country, their region, their accounts. You set it per
report, for each reader, and it is enforced on the server before any data leaves it.
Watch the 81-second walkthrough: Row-level security.
Read the announcement: Each viewer sees only their own rows.
Who is filtered, and who isn't
Row security applies to a report's readers:
| Who | What they see |
|---|---|
| Workspace Viewer | Only the rows that report's rules give them |
| Someone the report was shared with | Only the rows that report's rules give them |
| Editor | Every row. Editors build and fix the reports |
| Workspace Admin / workspace owner | Every row, and they manage the rules |
| Organization admin | Every row in their organization |
Anyone who can edit a report (Editors, workspace Admins, the owner and organization
admins) can set its row security.
Set it up
- Give the person the report. Add them to the workspace as a Viewer, or
share the report with them. Until they are a reader, they don't appear in the list. - Open the report and choose More (⋯) → Row security…
- Choose the Reader. Each one is listed with how they got the report: Viewer or
Shared with them. - Choose the Datasource. If the report uses only one, it's chosen for you. For
SQL Server and Azure SQL, also choose the Table the rule applies to. - Choose the Column that decides access, such as Country, Region, Branch or Account manager.
- Tick the Allowed values. The list is read from your data (up to 200 values). If a
value isn't there yet, type it into Other values, separated by commas. - Choose Add rule. The rule appears under the reader's name and applies the next time
they open the report.
To remove a rule, choose the bin icon next to it. Every rule added or removed is recorded
in your organization's Activity log.
How rules combine
- Several values in one rule (Country = Canada, Mexico): the reader sees rows matching
any of them. - Rules on two columns (Country = Canada and Segment = Enterprise): the reader sees
only rows matching both. - Values are matched exactly: there are no ranges, wildcards or "starts with" rules.
Rules belong to the report
A rule applies to one reader on one report. If you share a second report built on the
same protected data, give each reader a rule on that report too. Until you do, they see
no rows from it.
"Only my own records": @me
When every row carries an owner's email address (an account manager on each deal, an
engineer on each ticket), choose that column and tick Match the reader's own email
(@me). The reader then sees the rows that carry their own sign-in email address.
@me is set per reader, like any other rule: add it for each person who should see
their own records. Once it's set, their rows follow the data as new deals or tickets are
assigned to them, with nothing more to change.
Example
The Financial overview report uses the Northwind financial sample, with five countries.
| Person | Rule on this report | Total sales they see |
|---|---|---|
| Owner or Editor | none needed | $118.7M (all countries) |
| Canada manager (Viewer) | Country is Canada | $24.9M |
| Germany manager (Viewer) | Country is Germany | $23.5M |
| Americas lead (shared with) | Country is Canada, Mexico, United States of America | $70.9M |
| Colleague with no rule | none | no rows |
Totals, averages and charts are calculated from the reader's rows only. "Sales by segment"
for the Canada manager is Canada's split, not a filtered slice of the company total.
What readers see
A filtered reader sees the same report, with a note at the top:
Filtered for you — Country: Canada. It tells them why their totals are smaller than
the company's. They can't switch it off.
The same filter applies everywhere their data goes:
- every chart, table and KPI card, and the totals behind them
- answers from the report's assistant and from chat with your data (the assistant is told
their scope, but the server, not the AI, decides which rows it receives) - CSV exports and the data behind every visual
- the value suggestions the AI uses to understand your columns
Safe by default
Row security fails closed. When something is unclear, a reader sees less, never more.
- A reader with no rule on the report sees no rows from its protected data. They are
told no rows have been shared with them and asked to contact a workspace admin. - Outside a report, readers see no protected rows. Once a datasource has rules,
readers see it only through reports that give them rows, not in workspace chat. - No public access. A report built on a protected datasource can't be published,
shared as a public link or embedded, because a public link has nobody signed in to filter
for. Requests with nobody signed in (public links, embeds, the AI Connector's
organization token) get none of the protected rows. - A missing protected column means no data. If the column a rule uses isn't in a
result (a Transform step removed it, or another sheet is being read), the result is
withheld rather than shown unfiltered. - If access can't be checked, nothing is shown. For example, when the rules can't be
read, or the report a request comes from can't be identified.
How it's enforced
- SQL Server and Azure SQL (directly or through the on-premises gateway): before a
query runs, each reference to a protected table is replaced with a filtered copy of
that table, so grouping and totals are calculated from the allowed rows only. The query
is checked with Microsoft's own T-SQL parser. For a restricted reader, only a single
read-onlySELECTruns. A query that can't be checked is not run, and neither is one
that reads data in a way that can't be filtered (OPENQUERY,OPENROWSET, table-valued
functions and similar). - Uploaded Excel and CSV files, file links and REST APIs: rows are filtered as they
are read, before anything is drawn or calculated.
Supported datasources
| Datasource | Row security |
|---|---|
| SQL Server, Azure SQL (direct or via gateway) | Yes. Choose the table for each rule |
| Uploaded Excel and CSV | Yes |
| Public file links (OneDrive, SharePoint, Google Drive, Dropbox…) | Yes |
| REST APIs | Yes |
| PostgreSQL, MySQL, SQLite, Power BI semantic models, other connectors | Not yet |
Unsupported datasources show as not supported yet in the Datasource list, and rules
can't be added to them. Don't share reports built on them with people who should see
only part of the data.
Limitations
- Views and synonyms need their own rule. On SQL Server a rule applies to the table
you choose. If the datasource also exposes a view or synonym built on that table, add a
rule for the view too, or leave it out of the datasource's table list. - Rules are per report and per reader. There are no group or role-wide rules yet.
- Exact matching only. No ranges, wildcards or "starts with".
FAQ
Do Editors need rules?
No. Editors, workspace Admins, the owner and organization admins always see every row.
To check what a reader sees, give a test account Viewer access and a rule, then open the report with it.
I added a rule but the reader still sees everything.
Check that they are a Viewer or a shared reader, not an Editor or Admin in that
workspace. Builders are never filtered.
A reader sees "no rows have been shared with you".
They have no rule on this report for this datasource. Add one in More → Row security.
Remember that each report needs its own rules.
Can I still publish or embed the report?
Not while it uses a datasource with row security. Share it with people instead. They
sign in, and their own rules apply.
Do email subscriptions leak data?
No. Subscription emails carry a link to the live report, not its data. The recipient
signs in and sees their own rows.
Does the AI decide what a reader can see?
No. The server filters the data before the AI receives it. The AI is only told the
reader's scope, so it describes their figures correctly.
Related: Roles and permissions ·
Workspaces, roles and governance ·
Embed reports