skip to content

On Tableau Server, how is a capability resolved when one group allows it and another denies it?

level: middleimportance: must knowfreq 65%

answer

  1. capabilities resolve one at a time
  2. specific beats general, no beats yes
  3. two states look like no access, only one is loud
  4. the licence tier can veto the rule

basics

~20 s

A rule set directly on the user beats any group rule; among rules at the same level, Denied beats Allowed; a capability left Unspecified everywhere means no access. Site role, content ownership and project leader or administrator status override the result entirely.

solid answer

~50 s

Tableau evaluates each capability — View, Web Edit, Download Full Data, and so on — one at a time, not as a bundle. The order is: a **user-level Denied** wins first, then a **user-level Allowed**, then a **group-level Denied**, then a **group-level Allowed**; if nothing addresses the capability, it stays **Unspecified**, which means the user does not get it. So a person in an Allowed group and a Denied group is denied, because among group rules Denied wins — unless someone wrote a user-level Allowed on that content, which outranks both. Sitting above all of this: the user's **site role** caps what any rule can grant (a Viewer cannot be given Web Edit no matter what the rule says), and site or server administrators and project leaders effectively bypass the rules for content they administer. In practice you assign to groups only, avoid explicit Denied except as a deliberate exception, and use permission templates rather than hand-toggling capabilities.

code

text · 14 lines
text
User: alice   Site role: Explorer
Content: workbook "Revenue Overview"

Rules on the workbook:
  Group "Analysts"     Download Full Data: Allowed
  Group "Contractors"  Download Full Data: Denied
  (no user-level rule for alice)

alice is in both groups
=> Result: DENIED   (group Denied outranks group Allowed)

Add:
  User "alice"         Download Full Data: Allowed
=> Result: ALLOWED  (user-level rule outranks both group rules)

go deeper

for a junior

Know that access is granted capability by capability, that rules attach to groups or users, and that a Denied on a capability blocks it. You are not expected to recite the full precedence order yet.

for a middle

Be able to walk the precedence order out loud — user Denied, user Allowed, group Denied, group Allowed, otherwise Unspecified — and explain why Unspecified and Denied differ even though both block.

for a senior

Demonstrate the diagnosis path: check site role first, then effective permissions for the failing user, then hunt for a group-level Denied, and remember the workbook-versus-data-source split. Explain why explicit user rules are operational debt.

for a principal

Own the model itself: group-only grants, locked production projects, templates instead of hand-toggling, and a small number of well-named groups mapped to identity-provider groups so access reviews are possible at all.

## Permissions are per capability, not per person Tableau Server and Tableau Cloud do not grant "access to a workbook". They grant individual **capabilities** on a content object: View, Filter, View Comments, Add Comment, Download Image/PDF, Download Summary Data, Download Full Data, Download Workbook, Web Edit, Share Customized, Move, Delete, Set Permissions, and so on (the exact list depends on content type and version). Each capability is independently set to **Allowed**, **Denied**, or **Unspecified**, either on a group or directly on a user. Templates such as View, Explore and Publish are just pre-baked sets of these toggles. That means the question "can Alice see this?" is really a set of separate evaluations, and Alice can perfectly well be allowed to view a dashboard while denied the ability to download its full data. ## The evaluation order For one capability on one content object, Tableau resolves in this order and stops at the first match: 1. **Denied on a user-level rule** for that user. 2. **Allowed on a user-level rule** for that user. 3. **Denied on any group-level rule** for a group the user belongs to. 4. **Allowed on any group-level rule** for a group the user belongs to. 5. Nothing matched — the capability is **Unspecified**, and the user does not have it. Two consequences fall straight out. First, **explicit Denied is sticky at its level**: one Denied in one group beats Allowed in ten others. Second, **user-level rules are the escape hatch**: an explicit user Allowed overrides a group Denied, which is exactly why hand-written user rules make a site impossible to reason about six months later. Unspecified is not the same as Denied even though both produce "no access" here. Unspecified is *silent* — it leaves room for a rule elsewhere (a different group, a project default) to grant the capability. Denied is *loud* — it actively blocks and will keep blocking when someone later adds the user to a group meant to grant access. Use Denied only when you mean "never, even if someone adds them to the Analysts group". ## What sits above the rules **Site role** is a hard ceiling and it is where most confusion comes from. Role-based licensing gives users a site role — Creator, Explorer, Explorer (can publish), Viewer, plus the administrator variants and Unlicensed — and a permission rule can never grant a capability the site role does not permit. Set Web Edit to Allowed for a Viewer and the option simply will not appear for them. The diagnosis rule of thumb: if the permission rule looks right and the user still cannot do the thing, check the site role before you touch the rule again. **Administrators** (server and site) have full access to content on the sites they administer. **Project leaders** hold administrative rights over a project and everything in it. **Content owners** generally retain access to their own content. None of these are expressed as ordinary rules, so a permissions grid that looks watertight can still be visible to more people than the grid suggests. ## Where the rules come from New content inherits the **default permissions** configured on its project at the time it is published — for workbooks, data sources, flows and so on, set separately. A project can be **locked** (permissions managed at the project level, with per-item editing disabled, optionally applied to nested projects) or **customizable** (the content owner can change permissions on their own item). Locking is the main lever for making a site auditable: it means the answer to "who can see this?" is a property of the project, not of whoever published last Tuesday. ## How to keep it sane - **Grant to groups, never to users.** User rules are for genuine one-off exceptions, and every one of them is future debt. - **Prefer Unspecified over Denied.** Reserve Denied for a deliberate carve-out, such as blocking Download Full Data for a contractor group. - **Use templates** rather than toggling twenty capabilities by hand; hand-built rules drift from each other. - **Lock production projects** so permissions are inherited, and let sandbox projects stay customizable. - **Verify with the effective-permissions view** on the content item, which shows what a specific user actually gets and why, rather than reasoning about it in your head. When someone reports "I can see it but my colleague can't", the fast path is: check their site roles, then look at the effective permissions for the failing user on that item, then check whether any group they belong to carries a Denied.

  • What is the difference between setting a capability to Denied and leaving it Unspecified?
    Both mean the user cannot do it right now, but Unspecified is silent — another rule, such as a group added later, can still grant it. Denied actively blocks and keeps blocking even after someone is added to a group meant to allow it. Use Unspecified as the default and Denied only as a deliberate, documented carve-out.
  • A user has View allowed but still cannot open a workbook that uses a published data source. Why?
    Permission on the workbook is not permission on its data. If the workbook connects to a separately published data source, the user also needs the Connect capability on that data source; without it the views fail to render. It is the most common false alarm when teams move from embedded data to shared published sources.
  • What does locking permissions to a project change?
    Locking makes the project the single place permissions are managed: rules apply to all content inside it and per-item permission editing is disabled for owners, optionally cascading into nested projects. It trades flexibility for auditability, which is why production projects are usually locked while sandbox projects stay customizable.

saying these in an interview costs you the question

  • Says an Allowed anywhere is enough to grant access
  • Treats Unspecified and Denied as identical in effect
  • Ignores site role and keeps editing the permission rule
  • Grants capabilities to individual users instead of groups
  • Assumes a locked project still lets owners edit item permissions

context

resolving links…