dbt exposures are declarations in your dbt project of the downstream consumers of your dbt models — Tableau dashboards, Power BI reports, ML pipelines, and applications that read from tables your dbt project produces. Declaring exposures makes the full end-to-end lineage visible, from source data through transformation to the dashboards business users see.
dbt exposures are YAML declarations in a dbt project that document the downstream consumers of your dbt models — the dashboards, reports, machine learning pipelines, and applications that read from tables your dbt project produces. They extend the dbt lineage graph beyond the warehouse boundary, making it visible not just which models depend on which other models, but also which business dashboards depend on which warehouse tables.
Why Exposures Exist
A dbt project produces tables. Business users and analysts consume those tables through Tableau dashboards, Power BI reports, and other tools. Without exposures, dbt's lineage graph ends at the last model in the project — you know that the orders_mart model depends on the stg_orders staging model, but you cannot see that the CFO's weekly revenue dashboard depends on orders_mart.
The practical consequence: when you refactor orders_mart (rename a column, change a metric definition, alter the grain), you don't know what breaks. You can check your dbt models with ref() dependencies — those are tracked. But you have no visibility into which Tableau dashboards or Python notebooks are reading from orders_mart directly.
Exposures solve this by documenting the downstream consumers explicitly. With exposures declared, a developer can look at any model's lineage in dbt docs and see not just its upstream dependencies (where the data comes from) but its downstream exposures (who is using this table). Before refactoring orders_mart, you know to notify the owners of the revenue dashboard.
Exposure Declaration Syntax
Exposures are declared in YAML files in the models/ directory (often in a dedicated exposures/ subdirectory):
exposures:
- name: weekly_revenue_dashboard
label: Weekly Revenue Dashboard
type: dashboard
maturity: high
url: https://your-tableau-server/views/WeeklyRevenue
description: "Executive weekly revenue summary used in board reporting"
owner:
name: Sarah Chen
email: schen@company.com
depends_on:
- ref('orders_mart')
- ref('customers_mart')
Each exposure declares: its name and type (dashboard, ml_model, application, analysis, notebook), a maturity level (high/medium/low — used to communicate stability expectations), an optional URL, description, and owner, and critically — the dbt models it depends on via depends_on.
Exposure Types
dbt supports several exposure types, each communicating the nature of the downstream consumer:
**dashboard:** A BI dashboard (Tableau, Power BI, Looker, Metabase). The most common exposure type.
**notebook:** A Jupyter or similar notebook. Common for analytics engineering and data science work that reads directly from warehouse tables.
**analysis:** An ad-hoc analysis or SQL script with ongoing business value.
**ml_model:** A machine learning model or pipeline that reads training or inference data from dbt models.
**application:** A production application that reads from warehouse tables for operational purposes.
Exposures in dbt Docs
When you run dbt docs generate and serve, exposures appear in the lineage graph alongside models, sources, and seeds. You can navigate from a model to its exposures, or from an exposure to its model dependencies.
This makes the impact of changes visible: clicking on orders_mart shows that weekly_revenue_dashboard and ml_customer_ltv both depend on it. Any change to orders_mart requires coordination with the dashboard owner and the ML team.
Exposures and Data Freshness
Exposures can be combined with source freshness testing for end-to-end data freshness visibility. If you know that the weekly_revenue_dashboard reads from orders_mart, and you know that orders_mart refreshes from a source that had a freshness warning this morning, you can communicate proactively: "The revenue dashboard may show stale data until the source issue is resolved."
Without exposures linking dashboards to their upstream models, this communication requires manual investigation of what each dashboard uses — slow, error-prone, and likely to be skipped under time pressure.
Practical Adoption
Exposures are documentation — they are only as accurate as the person maintaining them. Starting with your highest-maturity, highest-stakes dashboards (the ones used for executive reporting, financial close, or regulatory reporting) provides the most value. Gradually extend to cover all significant consumers.
Combine exposure documentation with a process: when a new dashboard is created that reads from dbt models, a new exposure is added as part of the dashboard launch process. This keeps the exposure registry current without requiring periodic audits.
Our data architecture services includes dbt project design, documentation strategy, and data lineage implementation. Contact us to discuss your dbt implementation.
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 →