If you’re working with data, you’ve probably heard of dbt, the open-source tool that’s revolutionizing analytics engineering. dbt helps you transform raw data in your warehouse into clean, tested, and documented datasets for analytics and business intelligence. But what happens after your models are built? How do you track where your data is actually used? Like dashboards, reports, or machine learning pipelines?

That’s where dbt Exposures come in.

In this article, we’ll break down what dbt Exposures are, why they matter, and how you can use them to supercharge your data lineage, documentation, and change management. We’ll walk through practical examples, best practices, and tips to help you get started—even if you’re new to dbt.

What are dbt Exposures?

dbt Exposures are a feature in dbt that lets you document and track the downstream use of your data models. In simple terms, an exposure is a way to tell dbt, “This dashboard, report, or application depends on these models.”

Think of exposures as the bridge between your data warehouse and the real-world tools and people who use your data. They make your data lineage complete, showing not just how data is transformed, but also how it’s consumed.

Examples of exposures:

  • A Looker or Tableau dashboard
  • A Jupyter notebook for data science
  • A machine learning pipeline
  • An internal or external application using your data

Why is this important?

Without exposures, your dbt project’s lineage graph ends at your final model. With exposures, you can see the full picture—from raw data to business impact.

Why Should You Use Exposures?

Complete Data Lineage

Exposures extend your dbt DAG (Directed Acyclic Graph) to include dashboards, reports, and other end-uses. This means you can answer questions like:

  • “If I change this model, which dashboards will be affected?”
  • “Who owns this dashboard, and how is it used?”

Better Change Management

When you document exposures, you can quickly assess the impact of changes. No more spelunking through BI tools or Slack threads to figure out what might break.

Improved Documentation

Exposures populate a dedicated section in your dbt docs site, making it easy for data consumers to find context about how data is used.

Stakeholder Transparency

By documenting exposures, you show stakeholders that you understand and care about how data is used. This builds trust and makes you a strategic partner, not just a data black box.

Automated Testing and Selection

You can run or test all models that feed into a specific exposure, making it easier to ensure data quality for critical dashboards or applications.

How Do Exposures Work in dbt?

Exposures are defined in YAML files in your dbt project, usually under the models/ directory. Each exposure describes:

  • Name: Unique identifier (snake_case)
  • Type: How the data is used (dashboard, notebook, analysis, ML, application)
  • Owner: Who is responsible for the exposure
  • Depends_on: Which models, sources, or metrics power the exposure
  • Other properties: Description, maturity, URL, tags, etc.

When you build your dbt docs, exposures appear as nodes in your DAG and have their own section in the documentation.

Manual vs. Automatic Exposures:

  • Manual: You write the YAML yourself (most common)
  • Automatic: Some BI tools (like Tableau with dbt Cloud) can auto-generate exposures

Step-by-Step: Adding Your First Exposure

Let’s walk through how to add an exposure to your dbt project.

Step 1: Identify the Downstream Use

Pick a dashboard, report, or application that uses your dbt models. For example, a Tableau dashboard called “Executive Revenue Dashboard.”

Step 2: Find the Models It Depends On

List the dbt models (or sources, metrics) that power this dashboard. For example: fct_revenue, dim_date.

Step 3: Create or Edit a YAML File

You can add exposures to any YAML file under models/. Many teams create a dedicated exposures.yml file.

File structure example:

models/
  ├── exposures.yml
  ├── marts/
  │   └── fct_revenue.sql
  │   └── dim_date.sql
  └── ...

Step 4: Write the Exposure Definition

Here’s a real-world example:

version: 2

exposures:
  - name: executive_revenue_dashboard
    type: dashboard
    maturity: high
    url: https://looker.yourcompany.com/dashboards/executive_revenue_dashboard
    description: |
      Executive-facing dashboard showing monthly revenue KPIs.
      Used in monthly reviews for business units and end of month financial reporting.
    depends_on:
      - ref('fct_revenue')
      - ref('dim_date')
    owner:
      name: Joe Analyst
      email: joe.analyst@company.com

Step 5: Build Your dbt Docs

Run:

dbt docs generate
dbt docs serve

Now, your exposure will appear in the documentation, complete with lineage and details.

Code Examples: Exposure YAML Explained

Let’s break down the anatomy of an exposure YAML block.

Minimal Example

version: 2

exposures:
  - name: marketing_dashboard
    type: dashboard
    owner:
      name: Jane Doe
      email: jane.doe@company.com
    depends_on:
      - ref('fct_marketing_performance')

Full Example with All Properties

version: 2

exposures:
  - name: weekly_jaffle_metrics
    label: Jaffles by the Week
    type: dashboard
    maturity: high
    url: https://bi.tool/dashboards/1
    description: >
      Did someone say "exponential growth"?
    depends_on:
      - ref('fct_orders')
      - ref('dim_customers')
      - source('gsheets', 'goals')
      - metric('count_orders')
    owner:
      name: Callum McData
      email: data@jaffleshop.com
    tags: [finance, weekly]
    meta:
      department: finance
      priority: high

Property Reference

Property Required Description
name Yes Unique, snake_case name for the exposure
type Yes One of: dashboard, notebook, analysis, ml, application
owner Yes Name and/or email of the owner
depends_on Expected List of models, sources, or metrics (using ref, source, metric)
label No Human-friendly name (can include spaces, special characters)
url No Link to the dashboard, notebook, or app
maturity No high, medium, or low
description No Markdown string describing the exposure
tags No List of tags for organization
meta No Dictionary for custom metadata
enabled No true/false (can also be set at project level)

For a full list and details, see the official dbt exposure properties documentation.

Best Practices for Using Exposures

1. Document All Critical Dashboards and Reports

Start with your most important BI assets. If a dashboard is used for executive reporting or key business decisions, add an exposure for it.

2. Keep Owners Up to Date

Make sure the owner field is accurate. This helps with accountability and communication.

3. Use Descriptions and URLs

Provide clear descriptions and direct links to dashboards or notebooks. This makes your documentation more useful for everyone.

4. Tag and Organise

Use tags and meta fields to organise exposures by department, business unit, or priority.

5. Automate Where Possible

If you have many dashboards, consider scripting the generation of exposures using your BI tool’s API.

6. Review and Update Regularly

Set a reminder to review exposures periodically, especially after major changes to your BI tools or data models.

Advanced Tips: Automating and Integrating Exposures

1 . Scripted Generation

If you have dozens or hundreds of dashboards, writing exposures by hand can be tedious. Many BI tools (like Looker, Tableau, or Power BI) have APIs that let you list dashboards and their underlying tables. You can write a script to generate exposure YAML files automatically.

Example approach:

  • Use the BI tool’s API to fetch dashboard metadata
  • Map dashboard tables to dbt models
  • Output YAML in the exposures format

2. dbt Cloud Integrations

If you use dbt Cloud, some BI tools (like Tableau) can automatically create exposures for you. This reduces manual work and keeps your lineage up to date.

3. Use Exposures in dbt CLI

You can run or test all models that feed into an exposure using dbt’s selection syntax:

dbt run -s +exposure:executive_revenue_dashboard
dbt test -s +exposure:executive_revenue_dashboard

This is powerful for targeted testing and deployments.

4. Project-Level Configs

You can enable or disable exposures at the project level in dbt_project.yml:

exposures:
  +enabled: true

Common Pitfalls and How to Avoid Them

1. Not Keeping Exposures Up to Date

If you add or remove dashboards, make sure to update your exposures. Outdated exposures can lead to confusion.

2. Missing Owners or Descriptions

Don’t skip the owner or description fields. These are critical for documentation and accountability.

3. Overlooking Non-BI Exposures

Remember, exposures aren’t just for dashboards! Document notebooks, ML pipelines, and applications too.

4. Incorrect depends_on References

Make sure your depends_on list accurately reflects the models powering the exposure. Use ref, source, and metric as needed.

FAQs

Can I define exposures in any YAML file?

Yes! You can define exposures in any YAML file under your models/ directory. Many teams use a dedicated exposures.yml file for clarity.

What types of exposures are supported?

The type field supports: dashboard, notebook, analysis, ml, and application. Use the one that best fits your use case.

Can exposures depend on sources or metrics?

Yes. The depends_on field can reference models (ref), sources (source), and metrics (metric).

How do exposures appear in dbt docs?

Exposures get their own section in the auto-generated documentation and appear as orange “EXP” nodes in the DAG.

Can I automate exposure creation?

Yes! You can script exposure YAML generation using BI tool APIs, or use dbt Cloud integrations for supported tools.

Conclusion

dbt Exposures are a powerful, underused feature that can transform your dbt project from a collection of models into a living map of your data’s business impact. By documenting how your data is consumed—whether in dashboards, notebooks, or applications—you gain:

  • Complete, actionable data lineage
  • Better change management and impact analysis
  • Richer documentation for data consumers
  • Stronger relationships with stakeholders

Getting started is as simple as writing a few lines of YAML. As your project grows, exposures help you stay organised, transparent, and in control.

Don’t let your data lineage end at your warehouse. Use exposures to show the full story—from raw data to real-world impact.

Further Reading