Tableau Server, Cloud and Publishing
The governance plane under the dashboards
Tableau Server/Cloud publishes workbooks with data sources, schedules refreshes, enforces permissions and row-level security, and runs monitoring/usage analytics — the governance plane of Tableau.
What you will learn
- Publish workbooks and data sources with refresh schedules
- Model permissions and core-based row-level security
- Operate with monitoring and usage analytics
What is this?
Tableau Server (self-hosted) or Tableau Cloud (SaaS) is where workbooks and data sources are published for distribution. Published items carry metadata, refresh schedules (extract data sources), permission rules (site/group/project), and row-level security via user filters. Admins monitor data quality, adoption and performance through maintenance views and usage analytics.
Why do you need it?
- Publishing turns a lone viz into an operational, governed product.
- A refresh schedule & permissions make the dashboard trustworthy and safe.
- RLS user filters deliver one published source to many audiences.
- Operations (monitoring, backup, performance) is the difference between a toy and a platform.
Mental model
A retail pipeline: warehouse, delivery, checkout
Server publishing
The workshop (Desktop) makes pieces; the warehouse (Server) stores and ships them; the delivery van (refresh schedule) restocks on time; and the checkout (permissions) decides who's allowed in the aisle. Automated stock checks (monitoring) keep it from running out mid-shift.
How it works
- Publish from Desktop: choose server/cloud, project, data source + extract, and set permissions.
- Extract data sources refresh on named schedules; live sources connect through on-premises bridges for Tableau Cloud.
- Projects and groups define permissions; content inherits from the project unless overridden.
- User filters map logged-in users to row sets (RLS) for shared data sources.
- Usage analytics (Tableau 2021+, Cloud included) show who views what, load times and data quality signals.
Publish → refresh → secure → monitor.
Examples
The user-filter RLS portfolio
User filter: [E-Mail Address] IN { FIXED [Region]: LOOKUP(MIN([user-to-region][Region]), 0) } Published as: A data source with an extract schedule (every 6h) plus a workbook whose audience = the group "Region Managers". Result: one source, per-region rows on refresh, zero per-user extracts.A user filter restricts each viewer to their mapped region at query time — the published-data-source equivalent of DAX row-level security.
In production
- A data team publishes a certified sales data source; 12 teams build sheets on top without engineering each copy.
- An extract refreshing at 6am powers an executive view that must never show yesterday's stale numbers.
- Admins run usage analytics to retire the 30 dashboards nobody opens each quarter.
Best practices
- Publish the data source once, revoke per-workbook re-hosting, keep one version.
- Schedule refreshes with sensible staggering; fail loudly on missed runs.
- Model permissions by project/group — the fewest exceptions wins.
- Audit lineage and usage quarterly; remove unused sources and dashboards.
Common mistakes
- Publishing a fresh workbook with embedded data nobody can refresh.
- Permission exceptions strewn across workbooks instead of project structure.
- Live data sources with no bridge on Cloud, silently stale.
- Skipping monitoring — then a quietly-broken extract breaks the executive prep.
Debugging tips
- Refresh failed → open the data-source's refresh log; check credentials and schedule target.
- User sees no rows → the user filter maps them to nothing; check membership + filter logic.
- Dashboard lag → inspect the extract size and any live connections at peak.
Interview checkpoint
Quick quiz
What repopulates an extract with fresh data on a schedule?
User filters let one published data source serve many audiences with different row visibility.