Tableau
Intermediate 13 min read Tableau

Publishing and Governance

Ship workbooks safely, and keep them trustworthy after they ship

Publishing moves workbooks into Tableau Server or Cloud with permissions, data policies and refresh schedules. Governance is the invisible script that keeps shared analytics trustworthy.

publishTableau Server / Cloudpermissionsdata policyrefresh schedulecertified datarow-level security
Prerequisites: Dashboards and Stories
Before we start

What you will learn

  • Publish a workbook with correct permissions
  • Use data policies and row-level security
  • Set refresh schedules and audit access
Introduction

What is this?

Publishing prepares a workbook for readers in Tableau Server or Cloud: permissions decide who can read or download, data policies scope the rows or columns a user can see, and refresh schedules keep extracts fresh. Governance is the set of rules around who may publish, who may certify, and how access is audited.

Motivation

Why do you need it?

  • A published workbook is a shared asset; wrong permissions are a data breach waiting to happen.
  • Row-level security turns one workbook into many personalized views.
  • Refresh schedules are where staleness error messages actually begin.
  • Regulators require audit trails; Server tracks every access and export.
Think about it

Mental model

Imagine

A newsroom edit desk

Think of

Tableau governance

Reporters pitch (authors), editors approve publication (publishing rights), copyeditors certify accuracy (certification), and the wire editor checks the freshness of every feed (refresh schedules). The newsroom's rules are invisible but keep the paper trustworthy.

Mechanics

How it works

  • Publish sends the workbook plus data source to the server/cloud with a selected project.
  • Permissions map viewer/editor/certifier roles per user or group.
  • Data policies define rows/columns a viewer sees without editing the workbook.
  • Extract refresh replaces the snapshot on a schedule.
  • The server audit log records opens, exports, downloads and permission changes.

A governed publish flow.

Publish
Permissions
Policy
Schedule
Audit
Hands-on

Examples

A governed publish checklist

A governed publish checklist
1. Publish: workbook -> 'Sales Analytics' project,
   with a shared extract data source, not embedded.
2. Permissions: Sales group Viewer; BI group Editor.
3. Data policy: row-level scoping on region for non-admin groups.
4. Refresh: nightly 6:00 AM; failure alert to data-ops.
5. Audit: weekly review of the access log; revoke stale users.

The checklist ensures a single source is published once, scoped per group, refreshed on schedule and audited weekly — the difference between shared and governed analytics.

Real world

In production

  • A bank publishes a regional revenue workbook with a data policy scoping each manager to their countries, then audits downloads weekly.
  • An ERP team schedules 6am refresh for the nightly extract so the morning dashboard is always fresh.
  • A BI council certifies only curated sources; new workbooks using uncertified lookups get a 'review' flag.
Guidelines

Best practices

  • Publish the data source once and let workbooks reference it, not embed copies.
  • Use project-level templates to enforce permission patterns.
  • Enable row-level security at the source for sensitive fields.
  • Review access quarterly; revoke stale viewer groups.
Watch out

Common mistakes

  • Embedding the data source in each workbook so one fix requires re-publishing everywhere.
  • Giving default 'Viewer' access to everyone on the project, bypassing data policies.
  • Never scheduling a refresh, then debugging a stale-looking workbook.
  • Ignoring export controls: viewers can download data unless you block it.
Root cause analysis

Common issues

Error
Users see a stale extract despite the refresh succeeding
Root cause

The workbook references an embedded extract or the schedule refreshed a different source

Fix

Point the workbook at the published source and align refresh schedules.

Error
Row-level security not applied
Root cause

Data policy not attached to the right project group

Fix

Attach the policy to the group that actually loads the workbook and retest with viewer identity.

Error
Downloads show full data
Root cause

Export permission open to viewers

Fix

Restrict export/download permission and rely on the reader view.

When things break

Debugging tips

  • Check the workbook's data source connections: live vs extract vs published source.
  • Use the Server/cloud log for 'datasource extract refresh' failure entries.
  • When access surprises appear, diff the permission table before the workbook was republished.
  • Test a data policy as a dummy viewer account, not as an admin.
Interviews

Interview checkpoint

Practice

Hands-on lab

Publish with a Policy
25 min · intermediate
In progress
Objectives
  • Publish a workbook to a project
  • Attach a row-level data policy
  • Set a refresh schedule
  • Verify viewer access and audit entry

Publish with a Policy

25 min · intermediate

0/5 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/2
1

Which mechanism scopes rows per user without editing the workbook?

2

Embedding the data source in every workbook eases long-term maintenance.

Go deeper

Official documentation

Publish and share (Tableau)
docs
Tableau data security and governance
docs