When creating projects and publishing workbooks or data sources on tableau server, it’s very important to set the correct permissions for individual users and user groups. Unless capability is granted to a user or a user group, they will be denied access to the content, but uploading sensitive content without setting permissions correctly can cause a number of issues.
Permissions grant a user the ability to perform various actions within the content and these differ slightly for projects, workbooks and data sources. To set permissions, you need to go to the 3 dot ellipses next to the name of the project, workbook or data source and from here you will see an option for Permissions as shown below (for the Project called ‘Pat Lucas’):
Now I’m going to dive straight into the 3 key things to consider when setting permissions for a project/workbook:
Deny trumps Allow:
I guess this rule is a bit of a safety net within permission setting. Denying a user group access means that all individuals within that group cannot view the content of the project/workbook. Even if this user is in another user group that has been granted access to a specific project/workbook, they will still be unable to view because of the ‘Deny trumps Allow’ Rule. There is a way passed this that I will go into shortly.
For a Project, denying access looks like the image below with white crosses in red shaded boxes. In this case, ‘All Users’ cannot view or publish into this Project.
Individual access trumps group access:
This rule is pretty logical. Setting permissions on an individual user basis is much more specific than setting permissions on a group basis which is why Individual access trumps Group access. This is also the way passed ‘Deny trumps Allow’.
If an individual is granted access to a specific project/workbook, then regardless of whether they are in a user group who has their access denied, the individual will maintain access.
The graph below, taken from the Tableau website illustrates the Tableau Server Permission Rules in which you can see that questions related to individuals come before those related to groups.
The same goes if an individual user is specifically denied access. Regardless of whether they are in a group that has access allowed, the ‘Deny trumps Allow’ comes into play and they won’t be able to perform actions on the content.
Permissions on a project level can be locked and unlocked (customisable):
If permissions are locked, only administrators and project leaders can set permission rules. This is useful if you have a project in which the content is sensitive as the project leaders will ensure that permissions are carefully set. The content owners lose the ability to set permissions in a locked project and therefore can only set permissions in an unlocked project.
Locking permissions can be applied to nested projects or a parent project. If set at the parent project level, all nested projects will have their permissions locked.
Within the permissions window, you can change the permissions of the project to be locked or customisable by selecting the ‘Edit’ Button in the top left of your view, as highlighted below.
And there you have it - I hope this quick run-through on setting permissions was helpful and no awkward mistakes are made in the future!
Thank you for reading.