dbt tests failed: how to hand the actual rows to the business owner

A data test goes red, but the person who can fix the source record sees only a failed job name. In a 2026 practitioner discussion, a QA owner asks how to return the exact cells and primary keys behind failed assertions for business reporting. That is a different job from merely alerting the engineering team that a test failed.

Decide which failures need row-level evidence

Start with tests that have an actionable source owner: duplicate customer IDs, missing consent status, unmatched order references or invalid product codes. Define the identifier needed to find the source record, the sensitive fields that must be hidden, and the person allowed to correct it. Some aggregate anomaly tests cannot reasonably produce one offending row; do not force them into the same queue.

dbt documents store_failures and store_failures_as for persisting failed records. Verify the project's dbt version, configuration, schema and permissions before assuming a table exists. Inspect the compiled test query: the failure relation can only contain columns that the test returns. If business users need a source key that is absent, change the test's failing-record query or create a dedicated exception model.

Give exceptions a lifecycle

A usable exception record needs a stable key, test name, observed value, source system, run time, owner and status. Decide whether to retain every run or only current failures. Without retention rules, a cleared test can erase the evidence needed to explain what changed; without expiry rules, the queue becomes a graveyard of old issues.

Give the business team a narrow view of exceptions, not raw warehouse access. Connect a correction to a rerun and a closure signal. Where the defect is upstream, record a source-system ticket rather than editing the curated table by hand.

What success looks like

Measure time from failed test to identifiable source record, assignment and verified correction. A green dashboard alone can hide a recurring issue if the same source keeps reintroducing it.

Adovo’s view

Data quality is useful only when a failure can reach the person who can change it. The test tells us something is wrong; the exception contract tells us what to do next. Ship the row, the owner and the closure rule together. Otherwise the red light is just another dashboard.