Who Should See Which Numbers: Sharing Reports Without Leaking Them
The moment a report becomes useful, people want to share it — and a shared report is a permission decision wearing a friendly interface. Sharing with people versus roles, why sensitive fields need their own treatment, and the export that walks out of every control you configured.
A well-built report is the fastest way to move information around an organization, which is exactly why it is also the fastest way to move information somewhere it should not be. A salary column in a headcount report. A margin column in a report shared with a supplier-facing team. A customer list in a spreadsheet that left with somebody in March.
None of these are dramatic breaches. They are the ordinary consequence of a report being genuinely useful, shared with one more person than it should have been, and then exported.
Share with roles, not with people
A report can be shared with a specific user or with a role. Both work, and one of them decays badly.
Sharing with named people
- Correct on the day it is set up
- Never revisited when someone changes job
- Leavers keep access until somebody notices
- Nobody can answer "who can see this report?" quickly
- Grows into a list nobody understands
Sharing with roles
- A new finance hire inherits the right reports on day one
- A move between departments changes access automatically
- Leaving a role removes it without a separate action
- The answer to "who sees this" is a role name
- Stays comprehensible at forty people and at four hundred
The practical rule: share with a role by default, and with a named individual only for a genuine exception you would be willing to explain — an external auditor, a board member, a consultant on a defined engagement. Then review the individual shares quarterly, because that short list is where the drift lives.
Each share also carries what the recipient may do with the report, which is worth setting deliberately rather than accepting a default. Viewing a report and being able to change its definition are very different grants, and the second one quietly makes the recipient a co-owner of a number other people rely on.
Sharing with a named person is correct on the day you do it and wrong forever afterwards. Sharing with a role is the only version that survives people changing jobs.
Some columns are not like the others
Report-level access is a blunt instrument. Frequently the report is exactly right for the audience except for two columns — salary on a staff list, cost price on a stock report, a customer's phone number on an operational extract.
Field settings handle this at the level below the report: a field can be marked not visible, marked sensitive, or marked restricted for export. That third one is the interesting distinction, and it names something most access models miss — a column somebody may legitimately read on screen while doing their job, but should not be able to carry out of the building in a spreadsheet.
| Setting | What it expresses | Typical use |
|---|---|---|
| Not visible | This column is not for reporting at all | Internal identifiers, technical fields that only confuse |
| Sensitive | Reading this requires a specific grant | Salaries, personal identifiers, bank details |
| Export restricted | Readable on screen, not extractable | Customer contact lists, cost prices, anything whose risk is bulk copying |
Exporting sensitive data is its own permission
Running a report and exporting a sensitive one are separate grants in the permission model. That separation is doing real work: it lets you give a broad group the ability to see and use reports while keeping the number of people who can extract sensitive data small enough to name.
The export is where control ends
Everything described so far applies inside the system. The moment a report becomes an XLSX file, it enters an environment with no permissions, no expiry and no audit — a laptop, an email thread, a WhatsApp group, a personal drive. It will be there in three years, and it will still contain March 2026 salaries.
This is not an argument against exporting; people need to work. It is an argument for three specific habits.
-
Give scheduled delivery instead of export rights
Most people exporting monthly are doing it because they need the numbers monthly. A schedule that sends the report removes the reason to hold export permission at all.
-
Restrict at field level rather than refusing the report
A blanket refusal makes people ask a colleague to export it for them, which is worse — now the data has moved and nothing recorded who really wanted it.
-
Read the export log monthly
Report views and exports are recorded, with the actor and the format. Fifteen minutes a month reading who extracted what is the only control that operates after the file exists.
-
Ask leavers about their files
Not as an accusation — as a standard exit question. Most people have forgotten they have them, and asking is the only way anyone ever deletes them.
Report access is not row-level access
One boundary to be clear about before designing around an assumption. Sharing controls which reports a person can open, and field settings control which columns they contain. Neither restricts which rows a person sees within a report they have access to.
So a branch manager given a sales report sees the whole report, not only their branch. The workable pattern is one saved definition per audience, filtered to that audience, shared with the role that should see it — three branch reports rather than one report that filters itself per viewer. Slightly more definitions to maintain, and it is honest about what is actually enforced. The general shape of the permission model is covered in roles and permissions.
What we do and do not do
What AWRA OpsHub does today
- Shares to a named user or to a role, recorded with who granted them and what the recipient may do.
- Visibility on the definition itself, separate from explicit shares.
- Field-level settings — not visible, sensitive, or restricted for export — applied per field.
- Separate permissions for viewing reports, exporting, and exporting sensitive reports.
- Exports recorded with the actor, the format and the run behind them; report views are captured in the audit log.
- Scheduled delivery to users, roles or addresses, which removes most of the reason people hold export rights.
What it does not do
- No row-level security. A person with access to a report sees every row in it; filtering by branch, region or ownership means one definition per audience.
- No expiring or time-boxed shares. A share persists until it is removed, so external and consultant access needs a diary entry.
- No watermarking or download tracking after the fact. Once a file leaves, nothing follows it.
- No per-recipient filtering on a single schedule. One schedule sends the same output to everyone on it.
The first and last lines interact, and it is the combination that catches people: you cannot send one branch-performance schedule that shows each manager only their own branch. That is one schedule per branch, on one definition per branch.
A short review rhythm
- Quarterly: list every report shared with a named individual rather than a role, and justify each one. This list should be short and it never is.
- Quarterly: check external shares — auditors, consultants, board members — against whether the engagement is still live.
- Monthly: read who exported sensitive reports. Fifteen minutes.
- On every role change: the role-based shares follow automatically, but individual shares do not. That is the whole reason to prefer roles.
- Annually: re-read field settings against reports that have been added since. New reports do not know about decisions made a year ago.
Our take
Share with roles, keep individual shares to a list you could read aloud, and use export restriction at field level rather than refusing whole reports — refusal just moves the extraction to somebody else's account. Then replace standing export permissions with scheduled delivery wherever you can, because the file that never had to be exported is the only one that cannot leak.
See the custom report builder
Saved definitions shared with users or roles, field-level visibility and export restriction, separate export permissions and recorded exports.
Explore report buildingFrequently asked questions
Can we show a branch manager only their own branch's rows?
Not through sharing — there is no row-level security, so anyone with access to a report sees every row in it. The workable pattern is one saved definition per audience, filtered to that audience and shared with the appropriate role. It means more definitions to maintain, which is a real cost, but it is honest about what is actually enforced rather than assuming a filter that does not exist.
What is the difference between a sensitive field and an export-restricted one?
A sensitive field requires a specific grant to see at all — salaries, personal identifiers, bank details. An export-restricted field is one somebody may legitimately read on screen while doing their job but should not be able to carry out in a spreadsheet, such as customer contact lists or cost prices. The second names a risk most access models miss entirely: the danger is not reading one value, it is copying ten thousand.
Should we just remove export permissions from most staff?
Not bluntly, because a person who needs the numbers will ask a colleague to export for them — and now the data has moved with no record of who actually wanted it. The better sequence is to give scheduled delivery to everyone who exports on a rhythm, restrict at field level rather than refusing whole reports, and keep the sensitive-export permission to a group small enough to name. Then read the export log monthly.
Do shared reports expire?
No — a share persists until somebody removes it, and there is no time-boxed access. That matters most for external parties: auditors, consultants and board members who needed access for a defined engagement and still have it two years later. Put the removal date in a diary at the moment you grant it, and make external shares a standing item in your quarterly review.
Can one schedule send each manager their own version of a report?
No — a schedule sends the same output to everyone on its recipient list. Combined with the absence of row-level security, that means per-audience reporting is one definition and one schedule per audience. It is more objects to maintain, so keep the number of audiences deliberately small; three regional reports is manageable, thirty branch reports is a maintenance problem you will regret.
