Who should be allowed to see which report

The question arrives about three weeks after a team starts publishing reports, and it is always the same shape: the regional managers should see their own region, and not each other's.

This is an unremarkable requirement. It is also the point where a lot of reporting setups quietly fall back to sending PDFs by email, because the tool offers workspace-level access and the requirement is narrower than a workspace.

Two different questions

The mistake is treating access as one question. It is two, and they deserve different answers.

"May this person publish reports?" is about a capability. It belongs to a role — Builder, Analyst, Viewer — and it applies across the product.

"May this person open the Northern Region report?" is about one specific thing. Rolling it into a role means inventing a role per region, and then a role per region per seniority, and eventually nobody can say who can see what.

In Dashful these stay separate. A permission is either a feature — studio.dashboards.publish — or one particular report: reports.<id>.view. The instance form is what lets you say "this person sees their region" without a combinatorial explosion of roles.

The details that decide whether it survives contact with reality

A permission model is easy to design and easy to get subtly wrong. Three choices we would defend:

Reports are keyed by id and shown by title. Someone renames "Q3 Regional Performance" to "Regional Performance" and the grant survives, because the grant was never about the title. Two reports are also allowed to share a title, which in practice they do.

The wildcard is explicit. reports.*.view means every report, including ones published next month. Every built-in role carries it, so narrowing someone to named reports is a deliberate act rather than something you get by accident.

Nothing is cached across a request. Revoke a role and it takes effect on the next request, not whenever a cache expires. If you have ever had to explain why a removed employee could still open something for twenty minutes, you know why this matters.

Nobody gets locked out. Whoever runs the organisation always holds everything, whatever the roles say. A permission system that can strand its own administrator is a support ticket waiting to happen.

Two kinds of no

The last piece is about what someone is told. "Your role doesn't include that" and "your plan's limit has been reached" are completely different problems with completely different fixes — one is a conversation with an administrator, the other is a conversation with us.

They are checked separately and reported separately, so the reason a person sees is the true one. It sounds like a small thing. It is the difference between a support ticket and a person solving their own problem in thirty seconds.

Where to start

Map your identity provider's groups onto roles and let the directory do the work — everyone your IdP puts in BI-Admins is a Builder here. Then grant individual reports only where the narrower requirement genuinely exists. Most organisations need it in one or two places, not everywhere, and the ones that try to model every case up front are usually the ones that end up emailing PDFs again.