Who Sees What
A query tool that ignored permissions would be a way to read everything, so BI does not.
Where to find it
Architect Panel → Dashboards:
- Explore — access granted like any other screen
Architect Panel → Security:
- Permissions — what each group may reach
- Classification & Clearance — sensitivity controls that also apply here
The permission model still applies
Queries run as the user asking. Somebody who cannot see a datastore cannot query it, and row-level restrictions apply to results exactly as they do everywhere else. Classification and clearance apply too.
Aggregates can still disclose
This is the part worth thinking about carefully, because it is not intuitive.
A count of one, broken down finely enough, identifies an individual. "Safeguarding referrals by ward by month" in a small ward with one referral has disclosed that a referral exists and roughly who it concerns — even though no record was shown and every permission was respected.
Where you report on small populations, think about minimum group sizes before publishing a breakdown, and suppress or widen categories below a threshold. This is a well-understood problem in statistical disclosure control, and the fact that the tool enforced permissions correctly is no defence.
Who should get Explore
Explore is powerful and open-ended. Analysts and managers who need to ask their own questions should have it.
Most people are better served by a dashboard or a record pane answering the questions they actually have. Giving everyone an open query tool tends to produce many slightly different versions of the same number, and then arguments about which is right.
Sensitive datastores
Where casework classification and clearance apply, confirm the behaviour with a test account before opening BI more widely. Ten minutes of checking buys real reassurance, and it is the kind of thing an information governance lead will ask whether you did.
Exports leave the building
Anything exported is outside the permission model from that moment. A spreadsheet on a laptop is not governed by anything you configured here.
Where that matters, restrict export rather than relying on query controls alone — and remember that a scheduled report emailed as an attachment is an export.
Worked example
A council publishes complaints volumes by department monthly. Departments with fewer than five complaints in a month are grouped into "other" before publication, because a single complaint in a two-person team identifies both the complainant and the subject to anyone who knows the service.
Recommendations
- Set a minimum group size for anything published and apply it consistently.
- Give Explore to people who need to ask questions, dashboards to everyone else.
- Test sensitive datastores with a restricted account.
- Treat scheduled email reports as exports when deciding who receives them.