A Tableau governance framework defines who can publish what, where, and under what conditions — and ensures that the content users find in Tableau is accurate, current, and trustworthy. Without governance, Tableau environments accumulate untrusted content, inconsistent metrics, and abandoned workbooks that undermine confidence in the entire analytics function.
A Tableau governance framework defines who can publish what, where, and under what conditions — and ensures that the content users find in Tableau is accurate, current, and trustworthy. Without governance, Tableau environments accumulate untrusted content, inconsistent metrics, and abandoned workbooks that undermine confidence in the entire analytics function. The symptoms are familiar: users are not sure which dashboard to trust; the same metric shows different values in different workbooks; no one knows which data source is the authoritative one.
The Three Pillars of Tableau Governance
**Content governance** — defining what content exists in the Tableau environment, what quality standard it meets, and who is responsible for maintaining it. Content governance establishes the distinction between certified analytics (which the organisation officially endorses) and exploratory or personal analytics (which individual users create for their own purposes and may not be accurate or current).
**Data governance** — defining which data sources are authoritative, what business logic they apply, and who can access them. Data governance in Tableau is executed through published data sources: certified data sources that define the canonical versions of key metrics are the foundation of content governance.
**Access governance** — defining who can see what, who can publish where, and who can modify existing content. Access governance prevents both over-permissioning (users seeing data they should not) and under-permissioning (users unable to access data they legitimately need).
Project and Space Structure
Tableau Server and Cloud organise content in projects. Project structure is the primary mechanism for implementing governance at scale.
The standard governance project structure:
**A certified content project** (often named something like "Certified" or "Official Analytics") contains the content that the data team has reviewed, validated, and officially endorses. Publishing to this project requires data team approval. Content in this project carries the certification badge in search results. Users know that content in this project is accurate, current, and maintained.
**Departmental projects** for each business unit or team. Business units can publish content to their own projects with less friction than the certified project; content here is useful but not officially endorsed. Departmental projects allow teams to have working analytics without requiring every workbook to meet certification standards.
**Personal or sandbox projects** where individual users can publish exploratory work without any governance overhead. Content here is explicitly marked as personal and not endorsed.
**Archived or deprecated projects** where old content lives before decommission. Having a designated archive keeps old workbooks out of search results without immediately deleting potentially useful content.
This structure provides a spectrum from high-governance (certified project) to no-governance (personal sandbox), with clear signals to users about what level of trust each content category deserves.
The Content Lifecycle
A governance framework is only as good as the processes that maintain it. Content lifecycle management defines how workbooks enter the certified project, how they are maintained, and how they are retired.
**Certification review process** — when content is proposed for certification, the data team reviews: does the data source connect to an authoritative, well-governed source? Are the metric definitions consistent with the organisation's data dictionary? Is the content current (refreshed on a schedule appropriate to the data)? Is there a named owner who commits to maintaining it? The review process should be documented and consistently applied.
**Quarterly content audit** — all content in the certified project should be reviewed quarterly. For each workbook: Is it still in use (check access logs via the REST API)? Is the data source still current? Is the owner still responsible for maintaining it? Workbooks that are no longer used or no longer maintained should be moved to archive.
**Data quality warnings** — Tableau's data quality warning feature allows administrators to add a warning label to any data source or workbook that has known data quality issues: "This data source is being migrated; values may be incorrect until [date]" or "This data source was not refreshed this morning due to a pipeline issue." Using this feature proactively prevents users from relying on data that the data team knows to be unreliable.
User Role Framework
Tableau's permission system operates at multiple levels: site role (what can the user do across the entire site), project permissions (what can the user do in a specific project), and workbook-level permissions (what can the user do with a specific workbook).
The standard user role framework:
**Creator** — can connect to data, create and publish new content, and modify existing content they have access to. Reserved for analytics developers and data team members.
**Explorer** — can create visualisations and save to personal spaces, but cannot publish to shared projects without additional permissions. Appropriate for analysts who need more capability than viewers but who should not be publishing governed content.
**Viewer** — can view and interact with published content but cannot create or modify content. The most common role for business users who consume analytics.
**Site administrator** — full control over the site, including user management, project permissions, and site configuration. Should be limited to a small number of administrators who are responsible for the governance framework.
The permission model should be defined before users are onboarded and applied consistently. Granting permissions on an ad-hoc, request-by-request basis — the default in many Tableau environments — produces an unauditable mess of inconsistent permissions within a year.
Our Tableau consulting and managed BI practice designs and implements Tableau governance frameworks for organisations managing Tableau at scale — contact us to discuss governance design for your Tableau environment.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →