Managing Downstream with dbt Exposures: Organizing BI, App, and ML References

dbt exposures are a way to explicitly register the consumers of your data — dashboards, applications, ML jobs — inside your dbt project.

Exposures are metadata rather than executable nodes, but they are powerful entry points for lineage diagrams, the docs site, and selector-driven rebuilds. This article walks through implementation patterns and the points most likely to show up on the exam.

What Exposures Do and When to Use Them

Exposures are a resource type that declares external assets which consume dbt models or sources — BI dashboards, business apps, batch and streaming ML — in YAML so they participate in the lineage graph. Once declared, the dbt docs lineage view connects upstream and downstream nodes, and selectors can trigger rebuilds of the upstream side.

Three big payoffs: blast-radius visibility (which dashboards could break), change-driven rebuilds (use +exposure selectors to rerun only what's needed), and clear ownership (centralize contacts via the owner field).

• Exam angle: don't confuse exposures with executable nodes — they are metadata only.
• Operational angle: owner.email is essential as the first contact during incidents.
• Observability: use the docs site and lineage to make blast-radius review a routine practice.

Exposure Types and Definition Fields

type captures the nature of the downstream asset — commonly dashboard, analysis, application, or ml. Regardless of type, you list ref/source under depends_on and specify owner (name/email) and maturity (low/medium/high, etc.). url and description are too useful operationally to omit.

Exposures act as sinks in the lineage graph, with blast radius bounded by the upstream nodes listed in depends_on. When you add or replace models, verify that every derived mart a dashboard reads from is enumerated.

• Effectively required: name, type, owner.name, owner.email, depends_on
• Recommended: maturity, url, description, tags, meta
• Type selection: dashboard for BI, application for external products, ml for training/inference pipelines, analysis for ad-hoc analytical artifacts.

Lineage from models to downstream assets (exposures)

Implementation Steps, YAML Examples, and How Exposures Compare

Implementation is simple: add an exposures section to any schema.yml in your project. depends_on can mix ref and source. The example below ties a Looker dashboard to an executive KPI mart, the customer dimension, and a raw events source.

Use the comparison table to see how exposures divide responsibilities with models and sources.

• You can declare many exposures. Name them uniquely from the consumer's perspective.
• Match depends_on to the actual grain of reference — marts and aggregate tables.
• PR reviews should always validate owner and url.

Example exposures YAML definition

version: 2

exposures:
  - name: weekly_kpi_dashboard
    type: dashboard
    maturity: high
    url: https://bi.example.com/dashboards/123
    description: Executive KPI dashboard (weekly refresh)
    owner:
      name: BI Team
      email: [email protected]
    depends_on:
      - ref('mart_kpi_summary')
      - ref('dim_customer')
      - source('app', 'events_raw')
    tags: ['bi', 'executive']
    meta:
      tool: looker
      schedule_cron: '0 7 * * 1'

Operational Tips: Owners, Descriptions, Tags, and Meta

owner.email matters as the first contact during incidents. maturity helps prioritize change risk. url should always link to the actual dashboard or app. Keep the description short but include refresh frequency, SLO, and the definition of key metrics — that way the docs site alone is enough to make a call.

tags and meta drive governance. Label domain and criticality via tags. Put external tool identifiers (e.g., tool=looker, tableau, superset), operational schedules, and owning-team codes into meta so they're queryable — this makes inventories and impact analysis far easier.

• Naming: patterns like {domain}_{artifact}_{granularity} keep names unique and discoverable.
• Tighten review and notification for any maturity=high exposure when it changes.
• meta accepts organization-specific fields — great for cross-repo, cross-cutting governance.

Selectors, CI/CD, and Scheduler Integration

Exposures really shine when combined with selectors. +exposure:name picks the upstream of an exposure, enabling minimal rebuilds. This is useful for dashboard health checks and for regression testing scoped to a specific application's impact.

For diff-driven rebuilds, combine with state:modified so you only build the upstream of maturity=high exposures impacted by changed models — a sensible guardrail. In schedulers and CI, defining one job per business-critical exposure keeps operations predictable.

• Rebuild upstream: dbt build --select +exposure:weekly_kpi_dashboard
• List every exposure: dbt ls --select exposure:*
• Diff-driven: dbt build --select +state:modified,exposure:* --defer --state path/to/artifacts

CI example: health-check job for a critical exposure

dbt build --select +exposure:weekly_kpi_dashboard --warn-error --fail-fast

Exam Checkpoints (for Analytics Engineer)

Exposures are not executed. They are declared in YAML and surface in lineage and docs. Upstream rebuilds are driven by selectors (+exposure:...). These three points come up often.

depends_on can mix ref and source. owner.email is shown as a contact in the docs. type is a classification (dashboard, etc.) — it categorizes, it does not change behavior. These tend to appear as detail-level questions.

• Terminology: Exposure = downstream consumer asset, Model = transformation, Source = raw-data declaration.
• Selectors: the exposure: pattern is usable for selection, but the exposure itself is never executed.
• Docs: dbt docs generate also reflects exposures on the docs site.

Check Your Understanding

Frequently Asked Questions