Planning a Site
Before you add users and content to a site, we recommend that you plan the following aspects of a site. Details about each of these aspects of site administration are provided in this guide.
You can create projects on a site, which lets you organize related content. For example, you might set up a project to contain all the data sources and workbooks for a project that a group of your colleagues are working on together. Or you might set up different projects for different departments.
Projects are also useful because you can set up different permissions for each project. If you know what projects you'll need and who needs access to the content in those projects, it's usually easier to set up permissions before users publish content.
Every site has a default project named Default. As we explain later, we recommend that you do not use the Default project for content. Instead, use it to set up default permissions; when you create projects, the new projects get their initial set of permissions from the default project. In effect, the default project is a template for new projects.
Users and groups
Obviously, it's important to know who needs to access content on your site. Any user who will publish to the site must be able to sign in. If the user already has an account on the server, you'll need to add that user to the site. If the user doesn't already exist, you'll need to create a user account. Either way, make a list of the users who will need to be able to sign in to your site. (Users can belong to more than one site.)
Note: The server license might restrict how many users you can have. Tableau Server licenses are based on either cores or users. If the server has a user-based license, there's an upper limit to how many users can have active accounts on the server. Check with the server administrator to make sure that you'll be able to have an account for all your users.
In general, we recommend that you create groups on the server and then assign users to the groups. This makes it much easier to manage permissions, since you can assign permissions to a group, and all the users in that group automatically get those permissions. (See the next section.) It's typical to create groups for users who use content in similar ways. For example, you might create a group named SalesWBPublishers for all the users in the Sales department who publish workbooks, and a separate group named SalesDSPublishers for people in the Sales deparment who who publish data sources. (These groups need different permissions, so it makes sense to have different groups for these functions.)
Site roles and permissions
Each user has a site role that determines the maximum permissions that they can have on the site. For example, if you have the role of Site Administrator, you have full rights to work on the site. A user whose site role is Publisher can publish to the site, whereas a user whose site role is Interactor can interact with content (for example, change filter settings in a view), but can't publish. A user whose site role is Viewer can view content, but can't change settings in the content and can't publish.
As part of your site planning, decide what site role each user will have. (You can change a user's site role later if you need to.) A user with a site role that's too restrictive might not be able to do the work they need on your site. But by the same token, it's a security best practice to restrict users' permissions to only what they need in order to do their work (that is, to follow the principle of least privilege).
You must also determine what permissions a user needs in order to able to work with content. Each piece of content on the site (each workbook, data source, and project) supports certain capabilities. For example, a workbook has capabilities like View, Save, Filter, Web Edit, Add Comments, and Download, among others. Before a user can use a workbook—view it, save it, download it, add comments to it, and so on—that user must have permission for the specific capability. Therefore, you should map out what permissions users will need in order to be able work with content.
As we just noted, site roles act as an upper limit on permissions. It's actually the combination of site role and permissions that determines what a user can do. A user whose site role is Interactor can never publish to the site, no matter what permissions you grant that users. But a user whose site role is Publisher can publish a workbook to the site only if that user has permission to save and view workbooks.
To make it easier to manage permissions, create groups and assign the permissions to those groups. You can then add users to the groups that have the permissions that those users need. (Site administrators automatically have permissions for all the capabilities of all content, so they don't need to be explicitly assigned any permissions.)
If you are new to using permissions in Tableau Server, see Projects and Content Permissions in the Everybody's Install Guide for a walkthrough that uses a best practice approach to setting up permissions.
Extract refresh schedules
If users publish data sources or workbooks that include extracts, you usually want to make sure that the extracts are refreshed so that they contain the latest data. Users can manually refresh an extract, but this isn't always a good idea if the extract is large and the refresh takes a long time. Instead, you can set up schedules for when an extract should be refreshed. Another planning task for a site administrator is therefore to think about when extracts should be refreshed and to work out schedules.
Steps for setting up your site
The table below shows a loose sequence of steps for setting up a site. You can complete the steps in any order that makes sense for you. At the bottom of this topic you’ll find a list of links to more resources for each of the steps.
Before you configure the site, we recommend spending some time learning about site authentication, site roles, projects, and permissions. Create and document a plan for your projects, groups, and overall permissions strategy. Setting up a test project to experiment with different settings is a good way to iron out these issues. You can change many site settings after your users are working with the site, but try to go in with the intention of minimizing post-production changes.
|Configure site access||
If your organization uses single sign-on, you can configure your site to use SAML authentication. Otherwise, you can use the default Tableau ID authentication, where each user signs in using a user name and password.
Talk to your server administrator about whether single sign-on is something you want for your site.
|Customize site||You can customize how Tableau Server looks in order to personalize it for your company or group. You can change the server name that appears in the browser; you can add a company logo (used for all sites on the server). You can also configure language preferences and install custom fonts. See Customize the Server.|
Projects let you organize content and help you manage users' access (permissions) to data sources and workbooks that are published to your site. You can set default groups and permissions for all content on the Default project, lock the project, and then use it as a template for additional projects you create.
Projects can also serve as staging environments.
|Set up the permissions structure||
In Tableau, permissions work with site roles to make up a user’s access to the site and its contents.
Each user who accesses Tableau Server must sign in. Determine the users you want to be able to sign in to the site. If you enabled SAML authentication, determine which of those users will sign in with their single sign-on credentials, and which will use Tableau ID credentials.
|Get your data to Tableau Server||
We recommend that you designate a Tableau Desktop user who will publish vetted data sources to the site (that is, who will serve in the data manager role mentioned earlier). These published data sources can then be shared among your Tableau users.
As the site administrator, you can centrally manage data source permissions. Other attributes that either you or the data manager can maintain centrally are connection information (credentials, access tokens) and refresh schedules for cloud-based data sources. For more information, see Refresh Data on a Schedule.
|Analyze site usage and performance||
You can monitor usage, performance, and other metrics by reviewing the following Administrative Views: