Projects and Content Permissions
When your colleagues create workbooks in Tableau Desktop, they own that content. After content moves to Tableau Server, you need to decide who can access it and what they can do with it. As the administrator for a site on the server, one of your jobs is to manage permissions so that users can work with content to do their jobs.
This chapter provides an overview of projects and permissions. Although this guide is created for Tableau Server admins, permissions work the same on Tableau Online. To help you understand permissions, we provide a walkthrough to create users, assign each unique permissions, and then see what they can do as a result of your efforts.
In this chapter
In Tableau Server, permissions control who can work with what content.
Who means users and groups of users in your site. We briefly talked about groups in Creating Users. In this chapter we’ll show you how groups can help you manage permissions efficiently.
What means projects, workbooks, and data sources in your site—in other words, the content that your users will publish and share using Tableau Server.
Two general approaches for setting permissions are the open and closed models. In an open model, users get a high level of access—for example, all users can publish, and if necessary, you explicitly deny capabilities. This model can work when your organization is very small, and everyone has a similar level of responsibility.
In a closed model, users get only the access they need to do their jobs. This is the model security professionals advocate and the one we’ll use in this guide.
Every type of content supports a set of capabilities. Each capability represents an action that a user might perform on that content. For example, you can specify who can view, add comments to, or save a workbook, or connect to a data source.
You can set capabilities to Allowed, Unspecified, or Denied. If a capability is set to Unspecified for a particular group, users in that group cannot perform the associated task. We refer to this as an implicit deny. Permission for a workbook’s Save capability unspecified? Sorry, you can’t save that workbook.
Workbooks and data sources are always published to projects in Tableau Server. Use projects to:
Keep related content together. You might create projects based on audience (e.g. finance), role (e.g. administrators), or function (e.g. production versus sandbox).
Manage access to project content by different groups of users. This could mean granting different permissions to different groups for the same project. Or it could mean creating multiple projects that some team members can access and others cannot.
Set default permissions for all content in a project. Set the default permissions so that workbooks and data sources published to the project start with those permissions. We’ll show this in the walkthrough later.
Unless you deployed Tableau Server to support Guest users, every person who wants to publish content to or view it from the server must sign in as a Tableau user. And each user must have permissions to work with content.
To manage user permissions, 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.
A recommended practice is to create groups based on functional categories—Content Managers, Content Viewers, Data Managers, 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. A user can belong to multiple groups as well, meaning they get the permissions from all of those groups.
When you add a user to the site, you assign one of the following site roles: Server Administrator, Site Administrator, Publisher, Interactor, or Viewer. The administrator site roles get all permissions available for a site, regardless of the content permissions you set for those users.
For Publisher, Interactor, or Viewer, the site role determines the maximum permissions that a user will ever have on content. For example, if a user is assigned the Viewer site role, that user can never publish, no matter what permissions you grant that user on the site. Nor can that user be given permissions to interact with content.
Some users always have full access to content on your site, regardless of the permissions that you set on content. Full access means that the user can do everything with that content. The following types of users get full access to content:
Server administrators and site administrators. Users who have these site roles can access all content, anywhere on the site.
Content owners. When users with the site role of Publisher publish content to Tableau Server, by default, they become content owners for their published content. Content owners can set the refresh schedule and priority, edit, remove, save, and set permissions on their content.
Project leaders. Though it might sound like a site role, Project Leader is a project capability that can be set to Allowed. If you make someone a project leader, that person gets full access to all content published to the project. For more information, see What are project leaders? in this chapter.
The following example shows how group permissions and site roles can be set to control what groups are allowed to do with the content in a project.
Ashley and Adam need to publish and manage workbooks, and they are allowed to connect to data sources. They are members of the Content Developers group, and their site role is Publisher.
Henry needs to view and interact with workbooks, including edit views online. 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.
This next image shows what these groups and permissions might look like when you set them up in Tableau Server. You can see the assigned permissions for the different groups, and the effective permissions that each user gets (what they are actually allowed to do).
A—These are the permissions set up for the All Users, Marketing – Content Developers, and Marketing – Content Viewers groups.
B—These are the capabilities set for each group.
C—These are the users in these groups.
D—These are the actual permissions each user gets.
In this example, Henry, with the Interactor site role, can work with the workbooks online (use filters, download full data, share workbooks, and web edit). But Susan, with the Viewer site role, is limited to viewing-related capabilities only (view workbook, download an image of the workbook, download summary data, view comments, and add comments). In this case, the site role of users in the group determines the permissions the users ultimately get.
To show you how permissions work, we'll walk you through the process of setting up a project, adding some users and groups, and then giving them permissions. To follow these steps, you must be signed in as an administrator.
Set defaults in the Default project
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. In this case, as you'll see, creating the default permissions will actually consist of removing some permissions.
In the menu at the top of the page, click Projects.
Open the permissions for the Default project. Click the Actions menu (...), and then click Permissions.
Click . . . next to the All Users group name.
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 always 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 scenarios, the All Users group can make your life easier. The group has preconfigured 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.
But we're recommending a closed model, where you explicitly give users only the permissions they need. If users also get permissions from the All Users group, they might end up with permissions you don't intend. Or at least, it can be confusing to sort out what permissions users have and where they got those permissions.
So you just did something that we recommend for every site: remove all the permissions from the All Users group before you set any other permissions. We'll show you shortly how to set up the permissions you actually want to assign to users.
Create a new project
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.
For this walkthrough, you'll create four users. For the purposes of this illustration, you are going to create local users, all of whom you can delete when you are finished with this walkthrough.
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 temporarily create these users for you to use in this walkthrough. You'll also need to import them into Tableau Server.
Just for this project (not for your own projects), and to help you easily identify the user's site role and project role, you'll give them 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, click 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. Make sure you assign them the site roles that are suggested in their verbose names. (You can change these later if you need to.)
When you're done, you'll see a list of users like this one:
Plan your permissions
Before you start assigning permissions to groups, we recommend that you create a table or spreadsheet that lists groups (and who should be in the group) who will 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're using verbose names here just for purposes of the walkthrough. But notice that we're including the functional role of the members (Content Developers).
In the menu at the top of the page, click Groups.
Click New Group and then name the group Marketing – Content Developers.
Repeat these steps to create the other two groups. When you're done, you'll see a list of groups like this one:
Here's a tip: the permissions you set up later for groups will use the group name, so consider using descriptive, meaningful language when you name your groups.
Add users to groups
After you finish creating the groups, 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.
Assign permissions to the groups
Now that you've got users and you've assigned them to groups, we'll assign permissions to those groups to 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 the menu at the top of the page, click Content > Projects.
Select the Marketing project, click the Actions menu (...), and then click 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 is always listed, even if you've removed all permissions, as you did earlier.
Click Add a user or group rule, and then select the Marketing – Content Developers group.
Here you are creating 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.
The permission roles you see (Viewer, Publisher, Project Leader) are predefined sets of capabilities that make setup easier.
If a set of capabilities differs from a predefined role in any way, the role will be displayed as Custom.
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 permission 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.
View your permissions work
This is a good place to stop for a moment and 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:
About default permissions and locking permissions to the project
Even though you've set up a bunch of permissions in the project, there is no actual content in the project yet. You've set up default permissions for the project. The idea is that the default permissions will apply to workbooks and data sources when users later publish those types of content to the project.
But there's a twist. When users publish from Tableau Desktop, the publish process offers them the opportunity to set permissions on the content that they're publishing:
If you set up default permissions for a project, and a publisher has the option to set permissions, who wins? It depends on how you set up your project—and whether you set permissions to be managed by the owner, or locked to the project.
Managed by the owner means the publisher can add or edit permissions on content they published (and therefore own). They can do this in Tableau Desktop at publish time, or directly on the server afterward.
Locked to the project means all content published to the project uses the default permissions that the administrator set on the project. Content owners cannot change permissions, either on the server or during the publishing process.
Whether you lock permissions or to allow content owners to manage permissions is up to you and the purpose of the project itself. It might make sense to lock permissions in one project, but not in another. In this walkthrough, we'll show you how to lock permissions, for two reasons:
Permissions are not locked by default, so it's useful to see how to lock them.
This walkthrough demonstrates the closed permissions model, and locking permissions is an extension of careful and centralized management of content access.
Okay, let's proceed with locking permissions to the project.
In the menu at the top of the page, click Content > Projects.
At the top of the Permissions pane, click Managed by the owner.
In the dialog that appears, select Locked to the project, and then click Save.
When you save, the button in the Permissions pane changes to Locked to the project.
Now, in Tableau Desktop, the options to manage permissions during the publish process are removed:
How are default permissions used?
Before we move on, we need to say just a little more about how default permissions work in Tableau so you know what to expect. All workbooks and data sources that get published to the project will use the default permissions initially, like a one-time stamp of the default permissions. But what happens if you change the default permissions for the project after workbooks and data sources have already been published to a project?
If permissions are Managed by the owner, workbooks and data sources with the initial default permissions won't get the new default permissions until you lock permissions to the project.
If you edit the default permissions while permissions are Locked to the project, the changes are automatically pushed to all content in the project when you save the changes.
View the resulting user permissions (effective permissions)
So far, you've set up the explicit capabilities that you want groups of users to have. Even with the simple set of users you're working with, it might not be clear offhand whether a given user is allowed to save a workbook, connect to a data source, and so on.
What you need to know are the effective permissions that users in these groups have on content in the Marketing project. Effective permissions are the combination of these factors:
The user's site role. Remember that a site role determines the maximum permissions that a user can have.
The individual permissions explicitly assigned to the user (if any).
Individual user permissions on content take precedence over group permissions on content. What does that mean? Setting user permissions (especially for views) can make them unpredictable down the road. Setting group permissions helps you to avoid situations where a user has permission to view a workbook in a project that the user's group is not allowed to view.
The permissions explicitly assigned to all groups the user is a member of.
Whether the user is the content owner. By default, content owners have Allowed permissions for all of the capabilities of the content that they publish.
The implicit deny model. If a user hasn't been assigned permissions for a capability, the user cannot use that capability.
You can view effective permissions in the Tableau Server interface.
In the menu at the top of the page, click Content > Projects.
Select the Marketing project, click the Actions menu (. . .), and then click Permissions.
In the Permissions pane, expand the Projects column.
Click the All Users group.
This shows the effective permissions for every user for the Marketing project.
At the bottom of the pane, Tableau shows a list of the users in the All Users group (which is all users in the site). It also shows you the permissions for each user in that group. For example, you can see that some users have View and Save permissions, but users Henry and Susan have only View permissions.
Note: To publish content to a project, a user must have a Publisher site role plus View and Save permissions for the project.
Hover the pointer over the boxes in the lower pane, both the green boxes and the gray boxes.
A tooltip tells you why the box has the value it does. For example, if you hover over the Save box for user Susan, the tooltip tells you that this permission is Denied (not granted by any rule).
If you hover over the Project Leader box for user Susan, the tooltip tells you that this permission is Denied (by user's site role). Remember that Susan's site role is Viewer, and Viewers can never have the Project Leader permission.
In the top part of the Permissions pane, expand Workbooks. Click the Marketing – Content Viewers group to see the effective permissions for members of that group. Its members are Henry and Susan.
Because of his Interactor site role, Henry gets all of the permissions that were set for the group. But because of her Viewer site role, Susan gets a subset of the permissions.
Test permissions by publishing and interacting
The ultimate test of permissions is to actually 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 the users are not able to perform tasks that you have not granted them permissions for.
Start by testing users' ability to publish.
In Tableau Desktop, open the Superstore workbook (in Sample Workbooks).
Select Server > Sign In, and then sign in to your server as the administrator.
This ensures no other user will be the owner for this workbook.
Select Server > Publish workbook, and publish the workbook to the Marketing project.
Publish other workbooks as you choose.
Now try signing in to Tableau Server as different users to test what happens when they try to publish and perform other tasks.
Sign in to your server as Adam, and test out what you can do.
Sign out, and then repeat this exercise, signing in as Ashley, then as Henry, and finally as Susan.
Open the Marketing project, and then open the Superstore workbook.
Open the Forecast view in the workbook.
Notice the options available for interacting with the workbook. If Edit is available, notice whether the user is allowed to save the view.
For example, here is what Ashley sees when she is signed in. Ashley has full access to all of the options for interacting with the workbook, including editing. She has all download options, including being able to download the workbook.
Ashley has permission to save the workbook with a different name. For workbooks that she owns, she can save over existing workbooks.
Here is what Henry sees. He can save custom views, filter the view, edit a view, share views, download the view as an image or PDF, and download the data in the current view.
When Henry edits the view, he can change dimensions and measures, and use filters, but he is not allowed to save his changes.
Here is what Susan sees. Susan can share views, download the view as an image or PDF, and download the data in the current view. But she can't filter the view, save custom views, or edit the view.
This is the end of the walkthrough. You're done! Try this on your own with a real world permissions scenario. You should have enough information now to start setting up permissions on your own, but there's always more to learn. For more information, see Additional resources at the end of this chapter.
You might have noticed that we have a lot to say about permissions. More reference information is available in the online Help, but we wanted to mention just a few more concepts and tips here.
Permissions for data sources versus workbooks
Another important consideration in controlling access to workbooks and data sources on Tableau Server is that permissions control access to the workbook and to the published data source connection on the server.
But you can also control how you want to handle authentication between the workbook and the data source connection on the server (this happens when the data source is published), and between the data source and its database.
For more information, see the Connect to Data chapter in this guide.
Each of your projects can also have project leaders. Think of project leaders as mini-administrators for your site, but only for the projects they can access. It can be helpful to assign a project leader to manage the content in their project, so you, the administrator, don't have to.
Project leaders get full access to all project content and are allowed to do things like edit default permissions, lock and unlock permissions, change content owners, and move workbooks between the projects they "lead."
When you set the Project Leader capability in a group rule to Allowed, the users in that group automatically get all possible permissions for the project and its workbooks and data sources.
Giving someone the Project Leader permission results in giving them full access to content, even when that user doesn't have any other capabilities assigned.
Continue to Connecting to Data Sources.
Manage Permissions. A section in the Tableau Server Help that provides comprehensive documentation on the permissions model, how to manage permissions, best practices, and reference information on common permissions settings.
Connecting to Data Sources. A section later in this guide that covers how to optimize and control data access on Tableau Server.