Published data sources are the governance foundation of a well-managed Tableau environment. When done well, they ensure all workbooks in the organisation use the same definitions for revenue, customer, and order. When done poorly, they become a proliferation of similar-but-different data sources that no one trusts. This guide covers the patterns that make them work.
A Tableau published data source is a connection definition stored on Tableau Server or Cloud that workbooks connect to rather than maintaining their own embedded connections. The distinction matters enormously for governance: embedded connections mean each workbook has its own definition of what "revenue" means, how the customer dimension is structured, and which transformations apply. Published sources mean all workbooks share the same definition.
In a well-governed Tableau environment, published data sources are the governance backbone. In a poorly governed one, they become a proliferation of nearly-identical data sources with confusing names that no one can distinguish between — effectively defeating the purpose.
Published vs Embedded Connections: The Core Trade-off
When a workbook embeds its connection, it is self-contained — no dependency on a published source, no risk of a published source change breaking the workbook. The cost: each workbook is an island. Revenue calculated differently in ten workbooks means ten possible answers to the same question. An extract refresh schedule change must be made in each workbook separately.
When a workbook connects to a published data source, it inherits the source's definition, its extract schedule, and its field calculations. All workbooks connected to the same published source see the same calculation, the same data, and refresh at the same time. The cost: a change to the published source — a field removed, a calculation modified — affects all connected workbooks simultaneously.
The governance upside is the reason to use published sources at all: one place to define revenue, one place to manage extract schedules, one place to apply data security row-level filters. One change propagates everywhere consistently.
Certification: The Trust Signal
Tableau's certification mechanism applies a visible badge to published data sources that have been reviewed and approved as authoritative. Certified data sources appear first in search results and carry a visual indicator in the data connection dialog. The mechanism is simple; the discipline required to use it well is not.
Certification should mean: the data source has been reviewed by someone with authority over the definition, the data source has been tested for accuracy, the connection is maintained and monitored, and there is an owner responsible for it. If certification means "someone published this and clicked the certification button", it is decoration rather than governance.
The governance questions certification answers: Is this the right data source for my question? Can I trust the numbers it returns? Is someone maintaining it?
For certification to be meaningful:
- Define what certification means in your organisation: review process, quality criteria, owner requirement
- Assign a specific owner to each certified source — certification without ownership produces orphaned certified sources that eventually become inaccurate
- Review certified sources on a defined cadence (quarterly is typical): verify accuracy against source systems, verify the owner is still appropriate, verify the source is still in use
Naming Conventions
Published data source naming is where governance fails most visibly in Tableau environments. Common failure patterns:
- "Finance Data" vs "Finance Data v2" vs "Finance Data FINAL" vs "Finance Data - NEW" (no one can tell which is current)
- "Sales Dashboard Data Source" (named for the workbook it was created for, not what it contains)
- "Monthly Report Extract" and "Monthly Extract" and "Monthly Metrics Extract" (possibly the same source published three times)
A naming convention that supports governance:
[Domain] [Entity] [Grain] [Modifier if needed]
Examples:
- Finance Revenue Transaction (transaction-level revenue data from the finance system)
- Marketing Campaign Week (weekly campaign performance metrics)
- Customer Account Certified (certified account-level customer data)
The name should answer: what domain does this cover, what business entity does it represent, and at what grain. A new user searching for data should find the right source from its name without opening it to investigate.
Row-Level Security via Published Sources
Published data sources are the right place to implement row-level security. Row-level security applied in a published source applies to all workbooks that connect to it — the security policy is centralised rather than duplicated in each workbook.
Tableau supports two patterns for row-level security via published sources:
**User filter via USERNAME() or ISMEMBEROF()**: A calculated field uses USERNAME() to compare the current user against a data column or group membership. Rows not matching the current user are filtered. This approach does not require a separate entitlements table but is limited to simple user-to-row mappings.
**Entitlements table join**: The data source joins to a separate entitlements table (a table in the database mapping user to the dimension values they have access to) using USERNAME() as the join key. More flexible for complex security policies (user can see data for their region and any child regions), but requires maintaining the entitlements table in the source database.
For both patterns, the security filter must be in the published data source, not in individual workbooks. Security filters embedded in workbooks can be removed or circumvented by workbook editors. Filters in the published source cannot be overridden by workbook-level logic.
Extract Management for Published Sources
Published data sources with extracts centralise refresh management. All workbooks connected to the source refresh at the same time; there is one refresh schedule to manage rather than one per workbook.
Extract management best practices for published sources:
**Align extract frequency to actual data freshness requirements**: A daily extract refreshed every 15 minutes wastes compute and creates unnecessary extract failure risk. Refresh at the frequency where users would notice the difference.
**Monitor refresh failures centrally**: Published source refresh failures affect all connected workbooks. Backgrounder failures for high-priority published sources should alert the BI team before users report stale data.
**Document and enforce extract optimisation standards**: Published sources are shared infrastructure. A large, unoptimised extract that runs long and consumes significant Backgrounder capacity affects all users of that source. Apply the same optimisation standards (date filtering, row-level filtering, appropriate aggregation) to published source extracts as to any performance-sensitive operation.
**Version management**: Before making changes to a published data source (adding fields, modifying calculations), verify the impact on connected workbooks by reviewing the connected workbooks list in Tableau Catalog or via the REST API. Communicate planned changes to workbook owners with appropriate notice.
Project Structure for Published Sources
Published data sources should live in a separate project (or set of projects) distinct from workbooks. Common patterns:
- A "Data Sources" project containing all published data sources, with separate sub-projects by domain (Finance, Marketing, Operations)
- Certified sources in a "Certified" project with restricted permissions (only data team can publish; business users can connect but not modify)
- Working/development sources in a separate project where data team members can publish without affecting the certified layer
The project structure enforces the distinction between "certified, governed, trust this" and "working, provisional, proceed with caution." Mixing certified and uncertified sources in the same project undermines the certification signal.
Our Tableau consulting and managed BI services establish published data source governance frameworks as a foundation for analytics quality — contact us to discuss improving data source governance in 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 →