Structure Content Projects, Groups, and Permissions
When your Tableau authors want to share their data sources and reports (content) on your Tableau Server, they need to know where they should publish that content, so that the people they want to share it with can find it easily.
To publish or view content on Tableau Server, users must sign in to the server. After signing in, each user must have permissions to work with content.
As the Tableau administrator, part of setting up your server is to build a content management framework that meets the following goals:
Makes your permissions model predictable and scalable as your Tableau community grows.
Helps users to help themselves.
Note: Although this article is created for Tableau Server admins, permissions and projects work the same on Tableau Online, so you can use most of these guidelines for your Tableau Online site as well.
In this chapter
To set up a successful Tableau Server content environment, you coordinate the following pieces:
Groups—sets of users who need the same type of access to content.
Projects—containers for workbooks and data sources, each of which generally represents a category of content.
Permissions—sets of capabilities that define who can work with what content.
Tableau comes with a few pre-defined permissions roles. These are sets of capabilities for typical ways of using content. Applying a permissions role is easier to manage than granting or denying each capability manually.
Projects, data sources, and workbooks each have their own selection of permissions roles. We’ll take advantage of these in the walkthrough later.
We strongly recommend that you organize users into groups. You can then set permissions at the group level, to apply a set of capabilities to all users in the group. When you get a new Tableau user, just add them to the groups that give the access they need.
While publishing content, the publisher must select the project on Tableau Server in which to put their content. You use projects to keep related content together, whether you categorize by audience (e.g. finance), role (e.g. administrators), or function (e.g. production versus sandbox).
Projects are a great place to help users help themselves. You can set them up so that project names clearly indicate the type of content they hold, and that, of the total list of projects, each user sees only the projects they need to work with.
You can also create project hierarchies to sub-divide content within a top-level category. To learn more, see Use Projects to Manage Content Access and Permissions in Locked or Unlocked Project Hierarchies.
This example shows how group permissions set at the project level coordinate with site roles to determine who (which groups) are allowed to access which content in the project.
A good practice is to create groups based on functional categories—Publishers, Content Viewers, Data Stewards. Or even combine functional category with department; something like Marketing Viewers and Marketing Publishers. The point is to create groups whose members need to work with content in the same way. If you need to add a user to multiple groups, they get the permissions from all of those groups.
The following image shows a couple of groups for users who need different types of access to a project called Marketing.
In this scenario, two groups cover three types of user:
Ashley and Adam need to publish and manage workbooks. They are members of the Content Developers group, and their site role is Publisher.
Henry needs to view and interact with workbooks. He belongs to the Content Viewers group, and his site role is Interactor.
Susan needs to view workbooks online (with no other interaction). She also belongs to the Content Viewers group, and her site role is Viewer.
Remember that site roles determine maximum permissions. So you can put Susan and Henry in the same group and grant their group Interactor permissions on workbooks. Even though she has the permissions, Susan’s site role prevents her from accessing the interaction features.
In the walkthrough, we’ll explain further how to set the permissions roles to accommodate these three user types.
To show you how projects and permissions work, we’ll walk you through the following processes:
To follow along with these steps, you must be signed in to Tableau Server as an administrator.
Every site in Tableau Server has a Default project. The default project is designed to be a template for new projects in the site, and is useful for creating a default set of permissions.
While you’re signed in to Tableau Server as an administrator, select the Content menu at the top of the page, and then select Projects.
Open the permissions for the Default project. On the Actions menu (...), select Permissions.
Next to All Users (a default group), select the . . . button and then Edit.
Under Project, Workbooks, and Data Sources, select None.
Click Delete to apply the changes.
You just removed some permissions. What was that all about?
The All Users group deserves special mention because every site has an All Users group. And every user that you add to a site becomes a member of the All Users group. Every new project you create includes permissions for the All Users group.
In very simple or specific scenarios, the All Users group can make your life easier. The group has predefined permissions, meaning every user on the site already has a set of permissions out of the gate. The idea is that even if you don’t do anything with permissions, users can start publishing and using content on the server.
In our example, though, we want to show how to grant each group only the permissions they need. If users of those groups also get permissions from the All Users group, it’s hard to tell exactly what they will be able to do, and they might end up with permissions you don’t intend.
So if you decide to use this process in the future, just remember to remove permissions from the All Users group before you set any other permissions.
For the purpose of this walkthrough, you’ll create a project named Marketing.
In the menu at the top of the page, click Projects, and then click New Project.
Name the project Marketing, and then click Create.
Plan your groups and permissions
In your real world, before you start creating groups and assigning permissions, we recommend that you create a table or spreadsheet that lists groups for people who need access to content, and what you expect each group to be able to do. You can then refer back to your permissions plan later if needed.
Next, you’ll create two groups for these users. The groups will let you assign permissions to the users, based on what the users need to be able to do in the Marketing project. These are the groups you’ll be creating:
Marketing – Content Developers—This group is for users who can publish, edit, and manage workbooks, and connect to data sources.
Marketing – Content Viewers—This group is for users who can view and sometimes interact with content in the project, but can’t publish or save anything.
As with the user names, we give verbose names for purposes of the walkthrough. But notice that we include the functional role of the members (Content Developers).
Always use descriptive, meaningful language for your group names.
In the menu at the top of the page, select Groups.
Click New Group and then name the group Marketing – Content Developers.
Repeat these steps to create the other group. When you’re done, your list of groups look like the list in the following image.
For this walkthrough, you’ll add four local users, all of whom you can delete when you are finished with this exercise.
What if you’re using Active Directory?
If you’ve already configured Tableau Server to use Active Directory, you could have your Active Directory administrator to create these temporary users for you to use in this walkthrough. You’ll also need to import them to Tableau Server. After you have finished the walkthrough and feel confident that you can configure real users, you can delete the temporary users.
Just for the projects in this walkthrough (not for your own projects), and to help you easily identify the user’s site role and project role, you’ll give users verbose names in this form: <name> - <project role> - <site role>:
Ashley - Content Developer - Publisher
Adam - Data Analyst - Publisher
Henry - Content Viewer - Interactor
Susan - Content Viewer - Viewer
In the menu at the top of the page, select Users.
Click Add Users.
Click Local User, and then enter the user details for user Ashley. For Display name, use the verbose name, but use just Ashley for Username. Skip Email, and give Ashley the site role of Publisher, as it says in the verbose name.
Do the same to create the other three users, and assigning them the site roles that are suggested in their verbose names.
When you’re done, you’ll see a list of users like the one in the following image.
With your groups set up and users added to the server, you can add users to them.
In the menu at the top of the page, click Users.
Select Adam and Ashley, and then in the Actions menu (...), click Group Membership.
Select Marketing – Content Developers, and then click Save.
Follow the same steps to assign Henry and Susan to the Marketing – Content Viewers group.
Now we can establish who can do what.
At the risk of repeating ourselves, we’re not assigning permissions to individual users—users will get their permissions from the groups they’re in.
In Tableau Server, go to Content> Projects.
On the Marketing project, open the Actions menu (...), and select Permissions.
The Permissions pane shows the groups and users that you’ve assigned permissions to. Right now, the only group listed is the All Users group. This group is always listed, even if you remove all permissions from it, as you did earlier.
Click Add a user or group rule, and then select the Marketing – Content Developers group.
If you don’t see the group names, make sure Group is selected in the drop-down to the right.
Here you create a group permissions rule that will be associated with this project and its workbooks and data sources.
The page updates so that you can select permission roles under Project, Workbooks, and Data Sources.
These are the permissions roles we referred to earlier, which are predefined sets of capabilities that make setup easier.
If you select a role, and then assign capabilities to adjust what you want users to be able to do, the role will show as Custom. So if you can, try to avoid setting capabilities explicitly.
Under Project, select the Publisher permission role.
To see what capabilities are included for the role, click the expand icon next to Project.
Selecting the Publisher role sets the project’s View and Save capabilities to Allowed, but the Project Leader capability is left Unspecified.
Notice also that individual project capabilities are shown as icons. To see the capability name, hover over the icon. Or click the link above the icons to show capabilities captions.
Under Workbooks, select the Editor permissions role.
Under Data Sources, select Connector.
Click Save to save the permissions settings.
The combination of permissions for this set of permissions roles lets members of the Marketing – Content Developers group create and manage workbooks in the site.
Starting with step 3 of this procedure, repeat the steps to add the Marketing – Content Viewers group and set its permissions. This time, use the following permission roles:
Data Sources: None
The combination of permissions that are granted by this set of permissions roles lets members of the Marketing – Content Viewers group view and interact with content in the site, subject to the limitations of their site roles.
Leave the Permissions pane open for the next section.
Now, everything might be great if you stopped here. However, there’s a twist. During the publishing process, publishers have an option to set permissions on their content. In the closed permissions model that we’re advocating, you don’t want well-meaning publishers to mess up your nice, clean server. So we are going to lock the permissions to the project, making the option to set permissions inaccessible to publishers, even though they are still the content owners.
With the Permissions pane still open, above the matrix on the right side, click Edit Content Permissions next to the text that refers to unlocked permissions.
In the Content Permissions in Project dialog box, select Locked to the project, and then click Save.
Now when someone wants to publish to the Marketing project, they cannot change the default permissions you set on the server.
How are default permissions used?
Before we move on, allow us to elaborate on the workings of default permissions. All workbooks and data sources that get published to a project initially take the permissions set at the project level. Think of the content getting a permissions stamp upon entry to the project.
But what happens if you change the default permissions for a project after workbooks and data sources have been published to it?
If you edit the default permissions for a locked project, the changes are automatically pushed to all content in the project when you save the changes.
If you edit default permissions in an unlocked project, workbooks and data sources published after the changes will get the new defaults. However, existing workbooks and data sources will retain their initial default permissions until you lock the project.
Let’s check your work. The following images show what you’ll see in the Permissions pane when you’re done setting permissions for your groups.
When you expand Project, you see this:
When you expand Workbooks, you see this:
When you expand Data Sources, you see this:
Test permissions by publishing and interacting
If everything looks good in the Permissions pane, the next test is to go through the tasks that users need to do. You want to be sure that users can perform the tasks that they need to, and not tasks that you have not granted them access to.
From Tableau Desktop, take a turn signing in as each user and testing that user’s ability to publish workbooks.
Back in the Tableau Server browser environment, sign in as each user, and test access to editing and saving workbooks, interacting with views, changing ownership, setting permissions.
You should be able to set permissions only when you are signed in as a server or site administrator.
This is the end of the walkthrough. You stuck it out til the end!
Now you’re ready to try this with your real world permissions scenarios. You should have enough information now to get started setting up permissions on your own, but there’s always more to learn.
In particular, here are links to information in the Tableau Server Help about a couple of inconspicuous settings that can affect your workflow significantly:
Data access is evaluated differently for workbooks that connect to data sources that are published to Tableau Server.
The Project Leader permissions role can help you delegate content administration to the owners who know it best.
Learn about Project-level administration.
Finally, if you’re ready to work your way toward content management zen master, start here: Manage Content Access.
Continue to Connecting to Data Sources.