Declaring downstream exposures for a model

Exposures let you document downstream uses of your dbt project—like dashboards, notebooks, or applications—directly in your dbt project so that lineage and impact analysis extend beyond models into the tools that consume them. They are defined in YAML and appear in the dbt docs DAG, helping teams understand what breaks if an upstream model changes.

1 · Learn the must-know

• 1Exposures are defined in YAML files (typically under an exposures: key) and can live in any .yml file within your models directory, not just a dedicated exposures.yml.
• 2Each exposure requires a name, type (dashboard, notebook, analysis, ml, or application), owner (with name and/or email), and a depends_on list referencing models, seeds, or snapshots via ref() or sources via source().
• 3Exposures show up as distinct nodes in the DAG and dbt docs site, enabling stakeholders to trace which exposures depend on a given model and assess downstream impact before making changes.
• 4The depends_on field must use ref() or source() function syntax (not hardcoded table names) so dbt can resolve the dependency graph correctly and include exposures in selection syntax like dbt run --select +exposure:my_dashboard.
• 5Exposures do not run any code themselves—they are purely metadata/documentation nodes and have no compiled SQL or materialization.
• 6Common gotcha: forgetting to update or remove exposures when a downstream tool is deprecated leads to stale lineage information that misrepresents actual dependencies in dbt docs.

2 · Check your understanding