A permission question is asked like a lookup and behaves like a calculation. The inputs, the order they resolve in, why the answer takes six screens to reach, and what a read-only layer can tell you about it without touching anything.
Updated · 7 min read
Asking whether a particular person can open a particular dashboard sounds like a lookup. It behaves like a calculation, over inputs that sit in different places and get changed by different people on different days.
Six inputs, and the screen you happen to be looking at usually shows one of them. That is the whole difficulty, and it is a property of any layered permission model, not a fault in this one.
A capability resolves for a person in a fixed order, and knowing the order turns most surprises into a five-minute answer.
Two rules carry almost all of it. A rule written for a person beats a rule written for a group, and a denial beats an allowance at the same level. Most access surprises resolve to one of those two, usually the second, and usually because somebody joined a group carrying a denial set years ago for an unrelated reason.
Content inherits from where it sits. A project can hold a default template applied to content published into it, and a project can be set to manage permissions for everything inside it, which moves the decision from the item up to the project.
One consequence is worth saying plainly, because it is the one that surprises people mid-tidy: moving content changes who can see it. A move looks like housekeeping and behaves like a permission change. That is exactly why an offboarding plan raises a move between projects as a named risk while the plan is still read-only, before anything has been altered.
Publishing is the same event from the other side. New content lands under the target project’s rules, and the publish runs as the connected user, so it stops cleanly if that account lacks publish or overwrite permission on the target. Both of those are much better known before a promotion than during one.
Answering for one person and one dashboard means opening the view, the workbook, the project, the group memberships, the published data source and the site role. Six screens for one answer, and the answer covers one person.
Then it expires. The content was never touched and the answer changed anyway.
There is a direction problem underneath all of it. An access review asks who can see this. An interface built for daily work is arranged around what can this person see. Both are reasonable questions, they are answered by walking the same graph in opposite directions, and that is why the check taking ten minutes for one person takes a fortnight for a department.
Content permission decides whether the view opens. What appears inside it can be narrowed again by row-level filtering, whether that is a user filter in the workbook, an entitlement table joined into the data source, or a policy applied in the warehouse.
Two sentences are then true at once. Everyone in the group can open the dashboard, and each of them sees a different set of rows. Usually that is the design working exactly as intended, and it is also the most common reason two people compare screens and conclude the platform is broken.
Write down which mechanism is doing the narrowing, and where it lives. Field-level governance is inventoriable: a semantic layer profile counts what fraction of fields carry a classification decision and publishes it as one of the five components of its quality score. Anything counted can be reviewed. Anything held only inside a calculation somebody wrote in 2021 gets rediscovered the expensive way.
A governance layer sits on top of the site and inherits its rules rather than keeping a second set alongside them. Here that is written into the sign-in itself: every user connects with their own Tableau token, and that token, carrying their exact permissions, is the boundary for every read, every write and every assistant call made on their behalf.
Which gives the reading a pleasant property. What the product shows you is what you could already have reached, assembled faster and in one place. Answering a permission question this way needs no elevated account, and the reading itself changes nothing: the site browser is read-only by construction, with no publish path, no write endpoint, and nothing kept on disk beyond a session list of what you looked at recently.
Where the read is partial, it says which kind of partial it is. A metadata pull that meets a switched-off catalogue or a permission boundary returns an empty result with a readable warning and does not raise, so the report can distinguish found nothing from could not look. The risk score does the same from the other end: exposure, meaning how broadly the bearing content is permissioned, is held at a fixed value until that surface is enabled, and the published methodology states that in the same sentence as the score itself.
A partial view announcing itself is usable on Monday. A partial view that looks complete is the one costing you an audit finding, because everybody downstream reads it as coverage and nobody re-checks a green result.
The last two are what make it evidence, not a screenshot. A permission answer carrying a date, an author and a stated boundary can be handed to somebody else and re-run by them. Everything else is a memory of a Tuesday, and memories of Tuesdays are what access reviews are meant to replace.
Four things get called governance: certification, ownership, stale content and change control. Here each one is written as a check you can run, not an aim you can state. It also covers the one change that passes a visual review and is still wrong.
A person leaves. Their name stays on workbooks, schedules and subscriptions, and several of those fail without a sound. What they hold, what breaks, and the order that keeps the license recoverable.
A certification is a flag and a sentence, set by somebody who was sure at the time. What that asserts, what it leaves to you, who should hold it, and the three ways it quietly stops being true.