09 · Publishing to Tableau Public/Server

Building a workbook is half the job — this module covers getting the Orders dashboard (Level 1 Module 5, refined through Level 2) in front of an audience via Tableau Public or Tableau Server/Cloud.

1. Tableau Public vs. Server/Cloud

	Tableau Public	Tableau Server / Cloud
Audience	Anyone with the link (fully public)	Licensed users in your org
Data visibility	Underlying data is downloadable by viewers	Data stays behind auth
Cost	Free	Licensed (per-user or per-core)
Use case	Portfolio pieces, open journalism data	Internal BI, sensitive data

For the Orders dataset (sample data, no confidentiality concerns), Tableau Public is appropriate; a real company's actual sales figures would require Server/Cloud instead.

2. Publishing to Tableau Public

1. Server → Tableau Public → Save to Tableau Public, sign in, choose a workbook name (e.g. "Northwind Retail — Regional Sales").
2. Public requires the data source be an extract (not live) — since Orders is a small flat file, this is a non-issue; Tableau converts it automatically if needed.
3. After publishing, the workbook gets a public profile URL; embed code (an <iframe> snippet) is available from the "Share" button on the published view for pasting into a blog or portfolio site.

3. Publishing to Tableau Server/Cloud

1. Server → Publish Workbook, select the target Project (a folder-like container for access control) and data source publish option: embed the data source in the workbook, or publish it separately as a reusable, centrally-refreshed data source.
2. Publishing Orders as a separate data source (rather than embedded) means a second workbook (e.g. a Category-focused dashboard) can connect to the same already-cleaned Orders source without re-doing Prep work — the standard pattern once more than one dashboard needs the same data.
3. Set permissions at the project or workbook level (View, Interact, Download Full Data, Web Edit) — for a workbook containing real Sales figures, restrict "Download Full Data" for viewers who should only see aggregate dashboards, not export the 8-row source.

4. Extract refresh schedules

1. Once published to Server/Cloud, an extract-based data source can be attached to a refresh schedule (e.g. nightly at 2am) so the published .hyper file stays current without manual re-publishing.
2. For Orders, imagine new rows are appended to the source CSV weekly — a weekly Sunday-night schedule keeps the published dashboard's totals (currently 6880) accurate going forward without anyone touching Server.

5. Subscriptions and alerts

1. Subscribe Others (or self-subscribe) sends a scheduled email snapshot of a published view — e.g. a Monday-morning email of the Region Sales bar chart (2210/3750/920) to a sales manager.
2. Data-Driven Alerts: configure a threshold on a measure — e.g. alert if any Region's Sales drops below 900 (Central, at 920, is closest to this threshold in the current data) — Tableau emails automatically the next time the underlying data crosses that line.

6. Verifying a publish succeeded

1. After publishing, open the published URL (not the local .twbx) in a browser and confirm the Region totals still read 2210 / 3750 / 920 — a mismatch usually means the publish used a stale extract or an embedded copy of the data source diverged from the live source.
2. Check permissions by testing as a lower-privilege test account (or Server's "View As" feature) to confirm a viewer-level user cannot download the underlying 8-row table if that was intentionally restricted.

How It Actually Works

Publishing changes where the query pipeline built up across this course actually executes and who can trigger it — not what that pipeline computes:

1. Publishing an embedded data source bundles a snapshot of the extract (or the live-connection credentials/definition) inside the .twbx/server workbook object — every viewer's browser or Tableau Server process re-runs the same VizQL-generated queries against that bundled copy independently. Publishing the data source separately instead means multiple workbooks share one server-side copy of the already-cleaned Orders data and its one refresh schedule, so a Category-focused second workbook (Section 3.2) issues its own VizQL queries against the same underlying .hyper file rather than a second, independently-drifting copy.
2. A refresh schedule (Section 4) is mechanically just Tableau Server re-running the same Extract-creation pass described in Level 1 Module 2 — pulling fresh rows from the source, re-applying any extract filters and aggregation settings (Level 2 Module 8), and replacing the .hyper file's contents — every published workbook referencing that data source then queries the new file on its very next VizQL query, with no workbook-side republish needed.
3. Data-Driven Alerts (Section 5) work by Server periodically re-running the alert's underlying query (the same aggregate query the view itself would generate, e.g. SUM(Sales) per Region) on its own schedule, independent of anyone viewing the dashboard, and comparing the returned value against the stored threshold — this is why an alert can fire even when no human ever opens the dashboard: it's driven by a background scheduled query execution, not by a rendered view.
4. Permissions (Section 3.3) are checked before query execution is even allowed to reach the data layer — a viewer denied "Download Full Data" can still trigger the aggregate queries a dashboard needs (Region totals 2210/3750/920), but the row-level export path (which would otherwise return the raw 8-row Orders table verbatim) is blocked at the permission-check stage, before any row-level query is issued.

Cheat sheet

Task	Where
Publish (public, free)	Server → Tableau Public → Save to Tableau Public
Publish (org, licensed)	Server → Publish Workbook
Reusable data source	Publish data source separately from workbook
Set access	Project/workbook Permissions dialog
Keep data current	Extract refresh schedule
Recurring snapshot	Subscribe (self or others)
Threshold notification	Data-Driven Alert

Exercise

Design a data-driven alert rule for the Orders dashboard that would have fired historically: using the known Region totals (2210, 3750, 920), pick a threshold that only Central would cross, state the rule in plain language, and explain who should receive it and why.