Introduction
Defining a consistent content organization structure allows administrators to manage content and makes content more discoverable by users. Tableau Server gives you the flexibility needed to structure your environment and manage content based your specific requirements. Thoughtfully structuring your project will help you deliver true self-service analytics at scale and ensure the responsible use of data to enable your users to discover and share insights.
Michigan Medicine is not flat, and neither is the way you govern your content. Projects and nested projects behave much like file system folders to provide hierarchical structures that gather related data and content with the users, groups, and corresponding permissions that mirror your business. It is easy to delegate nested projects to Project Owners or Project Leaders for their specific needs. Common content management approaches include organizational (by department/team), functional (by topic), or hybrid (combination of organizational and functional).
Instructions
Projects
To share and collaborate, users will create and publish content to a project in Tableau Server. Projects are the default containers used to organize and secure content, holding workbooks, data sources, flows, metrics, and other nested projects within them. This creates a scalable structure for managing access to the content published to Tableau.
Top-Level vs Nested Projects
Top Level Projects
Top Level Projects must be created by the Tableau administration groups. In order to reduce duplication and improve organization requests will be evaluated to see if a new Top-Level project is required or the request fits into an existing project.
Child/Nested Projects
For example, in the initial Tableau Server deployment, the Sales, Marketing, and IT departments will be onboarded. Following the organizational structure, top-level projects for each will be created for every department. The users in these three departments, also happen to be part of the cross-functional Digital Transformation team. Because digital transformation content spans multiple departments' users, a separate project named Digital Transformation will also be needed. The users from each of their respective departments will be part of a group who can access them. Users and groups only see projects to which they have access, so do not be concerned with the number of projects that you see as an administrator.
Permissions should be managed at the project level using locked projects and groups to enforce governed access to content and simplify administration. While it is possible to manage permissions at an item level with unlocked projects, they will quickly become unwieldly to manage. Locked projects secure data while providing collaboration across projects when you need it. For more information, see Use Projects to Manage Content Access (Windows). A project can be locked at any level in the project hierarchy regardless of whether the parent is locked with different permissions.
Project-level administration
The project owner is always one individual user. By default, the user who creates a project is its owner. The project owner has administrative access to the project and content in it—including making someone else the owner and assigning Project Leader permissions.
The project leader setting provides a way to allow multiple users administrative access to a project, its child projects, and all workbooks and data sources in those projects. A project leader does not have to be a project owner.
Project ownership and project leader access in project hierarchies
In a multi-level project hierarchy, a user or group that is set as a project leader, at any level within the hierarchy, is implicitly given project leader access to all of that project's child projects and their content items.
To remove the project leader access, you must do so at the parent level in the hierarchy on which the ownership or setting was explicitly assigned.
Similarly, the owner of a project at any level has project leader access to all content in that project, as well as to any of its child projects, even if they do not own the child projects.
Only a project owner or administrator can change ownership of a content resource, and this can be done regardless of whether the project permissions are locked.
Actions project-level administrators can take on projects
Project leaders and owners can perform the tasks in the following list.
- Create and delete projects as follows:
- Project owners and project leaders can create and delete child (nested) projects in projects they own, or on which they have project leader status.
- Project owners can change ownership of their projects.
- Both project owners and project leaders can assign the project leader status to groups or users.
- Set permissions for a project, as well as the child projects, workbooks, and data sources in it.
- Lock permissions to apply the project's default settings to all workbooks, data sources, and optionally child projects and their content. For information, see Permissions.
- Permissions can be modified only from the project they're locked on. Only admins, the owner, or project leaders can change permissions.
- Move workbooks and data sources to another project to which they have project leader or owner access. Moving the project can affect permissions. For information, see Move content.
- Run, add, or remove extract refresh schedules.
See also Permissions.
Example: Project Organization
This example shows how a Project for the Internal Medicine project could be arranged.
Projects are used to separate content for
-
- Subject Areas (RVU Reporting)
- Departments or Teams (Finance)
- Project efforts and initiatives (Project A)
- Supporting Content (Datasources, Flows)
- Development areas or Sandboxes
The projects are used to control permissions for the content inside. The Internal Medicine project has the IntMed-AnalyticsTeam group assigned as the project administrators while the INTERNAL-MED-ALL department group can see the project.
Down one level in the Finance project we can see that the IntMed-AnalyticsTeam has Administer permissions since they are the project leads for the parent project. Also note that the IntMed-FinanceTeam has access to publish content in this project and the IntMed-Finance-DashboardAccess group can view the workbooks in it. A user in the dashboard access group might not have permissions to all the projects and won't be able to browse the folders, but they can still access the workbooks.
Since the permissions for the Finance project are locked publishers can't inadvertently grant permissions to unauthorized users.
Requesting a new project
If your project fits into an existing hierarchy then you just need to talk to one of the Project Leads or Owner so they can create it for you.
If you think you need a new top-level project first make sure it doesn't fit into an existing top-level project (list here). If you still think you need a top-level project request one.
Request will be evaluated to make sure that they don't fit into any existing projects so make sure to include details:
- Project Name: This should be a full name and not just an acronym ie. Internal Medicine (IM)
- Project Owner: This is the primary contact for this project who will be responsible for managing content and permissions.
- Project Lead group: An Active Directory group who will be Project Leaders and have similar access to the owner.
- Any details around what this request is for to help identify existing locations or content. Also a rough idea of the audience and what group will be owning the content.
I have a new project now what?
- Assign Project Leads to help with administration and as a backup. If there isn't a group for those users already request a new AD group, import it to Tableau Server, and make the group project leads.
- Plan how you want your project to be arranged with sub-projects and what permissions should be for each of them. This article from Tableau has details on how to design you projects.
- Start publishing content