Some folks find this diagram helpful:
Some additional info:
Note the text:
The initial permissions for a project are copied from the Default project. The initial permissions for a workbook are copied from the permissions for its project. The initial permissions for a view are copied from the permissions of its workbook. This is a one-time copy of the parent’s permissions. Changes to the parent’s permissions are not automatically applied to the children unless the new permissions are actively assigned to the contents.
Any item can have permissions that differ from the parent. For example, a group might not have permission to see Project X, but it may have permission to see a view that’s published to Project X. Tableau Server does not support hierarchical object permissions; however, it does provide an inheritance model for users and groups. If a user does not have a permission explicitly set to Allow or Deny, the setting will be inherited from the groups the user belongs to.
If you’re going to use the “Inherit” permission option then have a plan, “Inherit” (used instead of Allow or Deny) can get very confusing if you don’t know what’s being inherited but used in the right way you can get a lot of value from it, take this tip from the Server Permissions document (see Further Reading below):
Use the “Default” project as a permissions template for all other projects.
This is because all new projects will inherit permissions from this “default” project.
This is perhaps one of the most important best-practice tips available. Tableau ships with a built-in project called “Default” that cannot be deleted. The shipping permission settings for this “default” project are to allow “all users” (a built-in group) some basic abilities to view content. You have options here.
One option is to make the default project restrictive, and to explicitly deny all permissions. In this scenario, all new projects created will inherit this concept of “deny” from the default project – this could be useful for organizations that desire a locked down environment with “allowance” being the exception and not the rule. Another option is to make the default project interactive but read-only with no access to underlying data. By disabling “View Underlying Data” and “Download Workbook” for the default project, all new projects (and thus their content) will inherit these permissions – this could be useful for organizations that want to standardize on visualization access, while still restricting data and workbook access.
A third option is simply to remove “all users” from the “default” group. This means any new projects created are truly a blank canvass from a security perspective – this option could be useful for organizations that do not have a standard in place, or those organizations where the standards change from project to project.
These are choices, and your actual deployment can differ and be fully customized.
Here's an extended look into the factors involved in determining how Permissions work, including how they're inherited and resolved at runtime.
There's a link to a PDF file of a map of the environment. It's too big to fit into a web page and still be legible.
The map shows Permissions along with other Tableau Server elements that affect what Users can actually do - knowing that these other elements exist and influence things is really helpful when trying to diagnose why someone can't do something they should be able to, or less often why they can do something they shouldn't be able to.
I meant to send you a personal message--I appreciate your posts on Permissions, in particular. I agree--with limited staff, in particular, I find this is an area that can be extremely difficult to get just right.
Anyway, we had some folks voice some security concerns recently--and your post came at just the right time. I was, at the very least, able to convince some others around here that we are not alone in our struggles. Your post helped reinforce that this can be difficult to set up in a multi-tenant/enterprise environment.