I like to think of Tableau Server as a library, and like all good libraries, there are ways to store and sort the sweet, sweet knowledge within them. Sites and Projects do just this. Projects tend to be the everyday workhorse; Sites, on the other hand, operate on a more significant and less flexible level. Let’s cover some of the basics.
What are Projects?
These are the equivalent of folders, used to store, organise and manage content. In our library metaphor, these could be analogous to bookshelves. Projects can be assigned permissions to control access, and operate at a really useful level: when configured using the ‘Lock Permissions’ option, you can automatically apply a folder permissions to all of its contents, rather than laboriously setting many smaller permissions on individual data sources and workbooks.
What are Sites?
If Tableau Server is a library, perhaps you could think of these as sections, like fiction or non-fiction (albeit separated into two rooms with thick walls between them). The content and users of each site are totally separate — as they’re designed to be their own distinct little universe within the server — so each site has its own URL. Users can belong to multiple sites if added by an administrator, though content remains firmly divided.
Some points of difference and note
1. Moving content
| Sites | Projects |
| As they’re designed to be self-contained structures, you cannot easily move content between Sites. The content needs to be manually packaged, downloaded and re-uploaded, which… is tedious. | Just like folders on a PC, you can easily move workbooks between projects. |
2. Nesting Projects within Projects
Be careful: for Tableau Server versions earlier than 2020.1, you can’t lock permissions for nested projects.
What they’re good for
Sites
TLDR: Sites are best used when data separation and security is key.
Sites are great for separating “internal” content and that for (or of) third parties, such as clients or guests — as Tableau calls it, “true multi-tenancy needs”. Sites can be the best option when strictly controlled access is required to minimise the risk of undesirable data transfer.
Projects
TLDR: Projects suit most other cases where content needs to be organised and assigned permissions.
1. Projects work well when separating development or testing content from production content. Results can easily be moved between Projects.
2. Project Leaders can be assigned to Projects, allowing much-needed access and control over relevant content without having to provide Administrator privileges.
Those with the role of Administrator are above the reach of permissions applied within Tableau Server. In most cases, it’s desirable to limit Administrator roles to a select few.
3. When the important use case for Sites above does not apply, and multiple users need to access and use various bits of content: use a Project. Data sources cannot be shared between Sites, and re-uploading them to each Site is undesirable: more copies, more risk. Performance may also take a hit.
So there you have it: a simple introduction to Sites vs Projects. Happy Server-ing!
