Customer 360 Enterprise Data Platform — Denodo on Azure  ·  View 19 of 39  ·  Data

Data Quality

How a defect is detected, what it does to the record, and who is expected to fix it.

Editable source SVG draw.io All views
Detect Classify Expose Remediate Prove Completeness Missing email rule Warn dq_flag on the 360 CRM owner task Coverage 98.2% Validity Phone format rule Warn dq_flag on the 360 Source correction Valid 96.4% Uniqueness Duplicate candidates Block Held out of the 360 Steward merge Duplicates 0.4% Consistency Address conflict Warn Survivorship pick Precedence rule change Conflicts 1.1% Timeliness Stale cache check Block Row marked stale Forced refresh Freshness 99.5% Data Quality — Detected at the Source, Exposed on the 360, Fixed by the Owner The platform never silently repairs a value. It publishes the defect beside the record and routes the fix to the system that owns it. v 1.0 · owner Data & AI Global Practice · date 2026-09

Decisions

  • The platform never silently repairs a value. It publishes the defect beside the record and routes the fix to the system that owns it.
  • Two severities with different consequences: a warning flags the row and lets it through; a block holds it out of the 360 entirely. Only uniqueness and timeliness can block.
  • Rules run in Databricks with Soda Core against landed data and against federated samples, so a rule is testable outside the query path.

Why quality is not fixed in the view

  • Cleansing inside an integration view produces a customer record that exists nowhere else, cannot be reconciled with the source, and quietly becomes a second system of record. Flagging keeps the source authoritative and makes the defect somebody's work item.

Numbers

  • Current baselines: email coverage 98.2%, phone validity 96.4%, duplicate rate 0.4%, address conflicts 1.1%, freshness SLA met 99.5%.
  • Exceptions retained 90 days; anything unresolved after 30 days escalates to the data owner.