12.1 Certification, Data Quality, Lineage & Permissions

12.1 Certification, Data Quality, Lineage & Permissions

Governance helps users distinguish trusted content, understand dependencies, and act on warnings without assuming that every published asset is equally authoritative. Certification, data quality warnings, lineage, ownership, and permissions solve different problems.

Certification

A certified data source carries a visible trust indicator and a note identifying who certified it. Certification communicates organizational approval; it does not freeze the asset, prove every value correct forever, or grant access. Consumers still need permission to connect.

The authority to certify a data source is broader than only administrators. A Server or Site Administrator can certify. A Creator or Explorer (Can Publish) can also certify when that user is the project owner or has the Project Leader capability for the project containing the asset. A person who merely owns a data source, without the required project authority or administrator role, cannot necessarily certify it. Governance questions should test both site role and project authority.

Certification can be removed when an asset no longer meets standards. Establish review criteria such as documented ownership, validated definitions, refresh health, security review, and a recertification cadence. Avoid multiple indistinguishable certified sources for the same business concept.

Data quality warnings

A data quality warning communicates a condition such as stale data, maintenance, deprecation, or another important status. High-visibility warnings can surface on downstream content so consumers understand risk before acting. A warning does not modify rows, repair a failed refresh, or replace permissions. Resolve the operational issue separately and clear or update the warning when the status changes.

Certification and warnings can coexist. A generally trusted source may carry a temporary maintenance warning. Certification answers whether the organization endorses the asset; the warning answers whether a current condition deserves attention.

Lineage and impact analysis

Tableau Catalog, when licensed and configured, indexes supported external assets and Tableau content to show upstream and downstream relationships. Starting from a database column, a steward can inspect dependent tables, published data sources, flows, workbooks, and sheets that Catalog recognizes. Starting from a workbook, the steward can trace its sources. This supports impact analysis before renaming or deleting an upstream field.

Lineage is evidence about discovered dependencies, not a guarantee that every external script or unsupported connection has been captured. Confirm the environment's coverage. Before a schema change, identify downstream owners, inspect calculations that use the field, communicate the change, apply an appropriate warning, and retest after deployment.

Ownership, project leadership, and permissions

Ownership usually grants management capabilities for content, subject to the site's rules, role ceiling, and project policy. Project Leaders administer content within a project. Administrators have broader scope. These concepts are not interchangeable: owning a workbook does not make a user a Site Administrator, and being able to publish does not automatically grant certification authority.

In a locked project, content uses the project-level permission rules. This limits asset-level exceptions and makes group-based governance predictable. In a customizable project, eligible users can set child rules. Effective access combines the user's site role with group and user permission rules. An explicit Deny can override an Allow for the same capability. Use Tableau's effective-permissions explanation instead of guessing from one group membership.

Governed-source workflow

1. Place the asset in the intended project and assign an accountable owner.
2. Grant Connect, View, Web Edit, Save, and download capabilities only to appropriate groups.
3. Document fields, calculations, refresh policy, and data-quality checks.
4. Have an authorized administrator, project owner, or Project Leader review certification criteria.
5. Add a certification note that explains the scope and contact.
6. Use Catalog lineage before upstream changes and notify downstream owners.
7. Apply high-visibility warnings for current issues such as maintenance or deprecation.
8. Periodically review permissions, ownership, refresh health, warnings, and certification.

Scenario distinctions

If users cannot find a trusted source, improve naming, descriptions, project placement, and certification. If an upcoming column removal may break workbooks, use lineage and impact analysis. If data is temporarily unreliable, use a warning. If a contractor can see too much, repair permissions or row-level security; a warning is not access control. If a capable author cannot certify, inspect whether they are a project owner or Project Leader before assuming an administrator is the only solution.

Good governance combines clear signals with enforceable controls. Trust indicators help users choose; permissions and security determine what they may do; lineage helps stewards predict consequences; operational monitoring keeps the trust signal deserved.