How would you structure Tableau Server projects and permissions for self-service across many teams?

## What the question is really about The failure mode of a BI platform is not technical. It is four hundred workbooks, no owners, six versions of revenue and a permissions grid nobody dares change. Structuring a Tableau site is about making the default path lead somewhere maintainable, because self-service means you will not be reviewing each item. ## Shape projects around ownership, not topic The tempting structure is thematic — Sales, Marketing, Finance, Ops — which stops working the moment two teams both produce something about customers. The durable structure is **who owns and maintains this**, because that is what you need to know when it breaks, and it maps to the groups you already have in your identity provider. A workable pattern per team is two projects: - **Sandbox / Team Name — Work in progress.** Publishing open to the team, permissions customizable, visibility limited to the team. Nobody outside expects anything here to be right. - **Certified / Team Name.** Permissions **locked at the project**, publishing limited to a named author group, content owned by a team account or a named individual. Projects nest, so a top-level governed project can hold per-team children with the lock applied through the hierarchy. Keep the depth shallow — two or three levels — because deep trees make permission reasoning miserable. ## Make promotion the governance gate Everything you want to enforce should attach to the sandbox-to-certified move, not to the act of publishing: - the workbook connects to a **published, certified data source**, not embedded data; - there is a named **owner** who is not "whoever built it"; - there is a **refresh schedule** with a stated freshness expectation, and a freshness indicator visible on the dashboard; - the metric definitions match the agreed ones rather than being locally invented. This is a lightweight review, done by the team's own authors, not a central committee. Central committees become the bottleneck that pushes people back onto exports and spreadsheets. ## Permissions: groups, locks, templates Three rules cover almost everything. **Grant to groups only.** Individual user rules are the single biggest source of unreviewable access. Sync groups from the identity provider so that leaving the company or moving teams updates Tableau access without anyone remembering to. **Lock production projects.** Locking makes the project the one place permissions are managed and disables per-item edits by owners, optionally cascading into nested projects. Then "who can see this?" has one answer per project instead of one per workbook. Sandboxes stay customizable — that is the point of a sandbox. **Use templates, not hand-toggling.** Hand-built capability sets drift apart and nobody can later say which differences were intentional. Reserve explicit **Denied** for genuine carve-outs, such as removing Download Full Data from a contractor group, and leave everything else Unspecified so a later group grant can still work. Remember that **site role caps everything**: a Viewer cannot be granted authoring capabilities however the rules read, so licensing decisions are access decisions. And remember that admins and project leaders sit above the rules — the permissions grid is not the whole truth about who can see what. ## Sites versus projects A **site** is a hard boundary: separate content, separate user membership, no sharing across sites. That is exactly right for a genuinely separate tenant — an acquired company with its own compliance regime, an external client — and exactly wrong for two departments in one company who will inevitably want the same customer dimension. Splitting into sites to solve a permissions problem creates a duplication problem you cannot solve, because you cannot reference content across the boundary. Default to projects; escalate to sites only when you can name the isolation requirement. ## Where metric definitions live The hardest part is not access, it is meaning. Two dashboards showing different revenue destroy trust faster than any outage. The structural answer is to push definitions **down** — into the warehouse models and then into a small number of certified published data sources — so authors compose from agreed measures rather than re-deriving them in workbook calculations. Certification exists precisely to make the blessed source findable; if authors cannot find it in ten seconds they will build their own. ## Running it, not just designing it Governance decays without operations: - **Ownership review.** Content whose owner has left is orphaned; sweep for it on a cadence. - **Stale and unviewed content.** Track what has not been opened in months and archive it. Every dead dashboard makes the live ones harder to find. - **Refresh reliability.** Monitor failing extract tasks centrally, not through the owner's inbox. - **Publishing roles.** Review who holds authoring site roles; entitlement creep is real. - **Naming conventions.** Boring, unglamorous, and the difference between a searchable site and a junk drawer. ## The tradeoff to name out loud Every lock you add reduces the number of people who can ship something. Too little structure and you get sprawl and contradictory numbers; too much and analysts route around the platform entirely, which is worse because the sprawl becomes invisible. The right calibration is usually: **near-zero friction in sandboxes, real friction at the promotion boundary, and heavy investment in making the certified path the fastest one.** People follow governance when governance is convenient.