dbt Exposures: Documenting BI Dashboards in Your Lineage Graph

The lineage graph covered in Lineage Graph tells you exactly which models depend on which — right up until the data leaves dbt’s world and lands in a BI tool. From there, dbt has no visibility by default: it doesn’t know that sales_summary feeds the executive revenue dashboard, or that three different Looker reports all depend on customer_orders. Exposures close this gap by letting you explicitly declare downstream consumers as part of the project.

Declaring an Exposure

An exposure is a YAML declaration, similar in spirit to a source declaration but pointing outward instead of inward.

exposures:
  - name: executive_revenue_dashboard
    label: "Executive Revenue Dashboard"
    type: dashboard
    maturity: high
    url: "https://looker.internal/dashboards/executive-revenue"
    description: "Monthly revenue breakdown by region, reviewed weekly by leadership."
    depends_on:
      - ref('sales_summary')
      - ref('customer_orders')
    owner:
      name: "Analytics Team"
      email: "analytics@company.com"

Once declared, sales_summary and customer_orders now show this dashboard as a downstream node in the lineage graph — dbt’s dependency awareness extends one step past the warehouse, into an actual business artifact people rely on.

Why This Matters for Impact Analysis

Without exposures, “what breaks if I change this model” stops at the last dbt model in the chain — you can see that sales_summary feeds nothing else in dbt, but you have no formal record that it also feeds a dashboard leadership checks every Monday. With the exposure declared, that same impact-analysis question (covered generally in Lineage Graph) now correctly surfaces the dashboard as something that would be affected.

Exposure Types

exposures:
  - name: weekly_ops_report
    type: application
  - name: fraud_ml_model
    type: ml
  - name: finance_notebook
    type: notebook
  - name: executive_dashboard
    type: dashboard

The type field is primarily descriptive — it shows up as an icon/category in the documentation site, helping distinguish “a dashboard someone looks at” from “a downstream ML model consuming this table as a feature” from “a data science notebook,” each with a different practical blast radius if something changes.

Maturity: Signaling How Much a Consumer Depends on Stability

exposures:
  - name: exploratory_finance_notebook
    type: notebook
    maturity: low
  - name: sec_filing_report
    type: dashboard
    maturity: high

maturity: high signals this consumer is production-critical and stable — changes upstream should be reviewed carefully. maturity: low signals an exploratory, less formal consumer where more flexibility exists. This is a documentation convention, not an enforced rule, but it’s a useful signal for anyone deciding how carefully to review a change to an upstream model.

Owner Information for Accountability

owner:
  name: "Finance Analytics"
  email: "finance-analytics@company.com"

When an upstream model change is about to affect a dashboard, the exposure’s owner field tells you exactly who to loop in before making the change — rather than discovering after the fact, when the dashboard breaks, that a completely different team than expected was actually relying on it.

A Practical Workflow: Checking Exposures Before a Breaking Change

Before making a schema change to a model with downstream exposures, checking what’s declared against it is a quick, high-value habit:

dbt ls --select sales_summary+ --resource-type exposure

exposure.my_project.executive_revenue_dashboard

This immediately tells you: this specific dashboard, owned by this specific team, needs to be considered (and probably notified) before you ship a breaking change to sales_summary.

Exposures and the Documentation Site

Every declared exposure appears in the generated documentation site (covered in dbt Docs Generate and dbt Docs Serve) as a distinct node type, complete with its URL, owner, and description — turning what would otherwise be tribal knowledge (“oh yeah, I think marketing uses that table for something”) into something documented, searchable, and visible in the same place as everything else about the project.

Keeping Exposures From Going Stale

Exposures share the same risk as any manually maintained documentation — if a dashboard is retired or its underlying query changes to use different models, the exposure declaration needs to be updated or removed, or it starts pointing at a stale, misleading dependency. There’s no automatic mechanism enforcing this; it depends on the same team discipline that keeps model descriptions accurate.

Tags Combined With Exposures

Since exposures are just another node type in the same project, they can carry tags too, letting you group dashboards the same way you’d group models — by team, by criticality, by review cadence.

exposures:
  - name: executive_revenue_dashboard
    tags: ['critical', 'team_finance']
    depends_on:
      - ref('sales_summary')

# Every critical-tagged exposure, to review before a major upstream migration
dbt ls --select tag:critical --resource-type exposure

This combination — tags for grouping, exposures for declaring real downstream consumers — is what lets a large project answer “which of our most important dashboards would be affected by this change” as a single, precise query instead of relying on someone’s memory of which reports matter most.

Common Mistakes

Not declaring exposures for the dashboards that actually matter most. The lineage graph’s usefulness for real business-impact analysis depends entirely on exposures being declared — skipping this for high-stakes dashboards defeats much of the point.

Letting exposure declarations drift out of sync with reality. A dashboard that no longer uses a particular model, but still has a stale depends_on entry, misleads anyone checking impact analysis against it.

Treating exposures as purely decorative documentation. Their real value is operational — checking them before making a change, and notifying the declared owner, not just having them exist as metadata nobody consults.

Summary

Exposures extend dbt’s lineage awareness one crucial step further — from “which models depend on which” to “which actual business decisions depend on this data,” which is ultimately the question that matters most when deciding how carefully to handle a change.