Plan and run data quality monitoring
Effective data quality in Atlan inverts the legacy approach: start with the handful of assets the business can't run without, not "how many rules can the team create." Data Quality Studio (DQS) lets you define, schedule, and monitor rules that execute natively inside your own warehouse, with results surfaced in Atlan alongside lineage and governance. This guide covers how to scope, sequence, and route monitoring well. For warehouse roles and grants, follow the DQS setup docs; for which warehouses are supported today and current feature status, confirm in the product reference—this page is about how to approach the work.
When to use what
Lead with criticality, not coverage. Identify the 10–20 assets tied to a named report or decision, apply the right checks without an engineering bottleneck, and monitor trust proactively. The success signal is "the data that matters most is monitored," not catalog-wide rule counts.
DQS validates against five dimensions:
| Dimension | What it checks | Typical rule types |
|---|---|---|
| Completeness | null / blank counts and % | null check, count/percentage |
| Uniqueness | duplicates, redundancy | uniqueness (composite keys typically need a custom SQL rule—confirm current template coverage in the product reference) |
| Validity | pattern / value correctness | regex, valid-values / IN-list, min/max |
| Timeliness | freshness / recency | freshness |
| Consistency | cross-field / business logic | custom SQL |
- Template rules are the no-code, business-user-facing default. Custom SQL rules are the escape hatch for composite-key uniqueness, cross-table checks, casting around wrong column types, and time-scoping.
- AI rule suggestions break blank-slate paralysis by proposing candidate rules from asset metadata. Run them as a cold-start, then filter by business criticality—never apply all suggestions unfiltered, because noise dilutes trust. Whether a profiling run is required for suggestions can vary—confirm in the product reference.
- Rule level: put a rule at column level where business criticality attaches to a specific field, and at table level for freshness, row count, and volume.
Where does DQS fit against other tools?
| If you need to… | Use… |
|---|---|
| Run engineering-owned tests inside the pipeline (for example, dbt, Great Expectations) | Keep those in the pipeline—they're complementary, not a replacement. Those are pipeline-execution tests; DQS is business-user-facing monitoring on the consumption layer with no-code authoring and AI cold-start. Pipeline test results can surface read-only in Atlan alongside DQS. |
| Simply display results from an existing observability tool (for example, Monte Carlo, Soda, Anomalo) | The integration—surface those results on the asset page. You don't need DQS rules for this. |
| Have Atlan write and run the rules | DQS. |
| Gate or block a pipeline | DQS can't do this—see below. |
Can DQS gate a pipeline? No. DQS is post-fact monitoring—it runs checks on data that has already landed in tables, so it can't intercept rows before insertion or halt an ETL/orchestration step. Because it's post-fact, don't rely on it for enforcement—instead use change-triggered scheduling plus alerting, and wire enforcement in your own orchestrator (a step calls the run-now API or consumes a failure signal and decides whether to proceed). For certification-gated workflows, a DQS pass/fail is a prerequisite signal a steward checks—still human- or orchestration-driven, not an automatic gate. Confirm current gating capabilities in the product reference.
Recommended sequence
Getting started—which rules first:
- Pick the single highest-stakes downstream report or decision as the pilot—not query-popularity alone.
- Run AI rule suggestions as the cold-start.
- Filter to columns with prior real pain or material downstream impact.
- Stand up 3–5 foundational checks (nulls, uniqueness on keys, freshness/volume) before any business-logic rules—foundational checks are fast and don't need SME input.
- Set a concrete milestone (for example, 10 rules across 5 critical tables by month-end).
- Treat the first domain as a pilot to replicate.
Run the initial setup as a hands-on working session that ends with rules live against pre-identified assets—a session with no target assets picked in advance ends inconclusive.
Long-lead dependencies to start early: DQS runs inside your warehouse, so it needs warehouse setup (roles, a dedicated DQ warehouse, and credentials separate from the crawler) completed before you enable it in Atlan and start authoring rules. Confirm lineage exists before deciding rule placement—defer rule design until the miner/lineage is confirmed, or rules land on the wrong layer. Follow the DQS setup docs for the exact grants and warehouse objects; don't reconstruct them from memory.
Scheduling: scheduling is set per asset, so choose a cadence that matches the load pattern and the business question—freshness and volume daily, expensive validity checks less often. Rules consume warehouse compute, so scope them deliberately and right-size the DQ warehouse to control spend. Where supported, run business-days-only to suppress weekend false positives.
Route alerts without creating noise
Rules are first-class assets—they carry an owner, tags, a domain, and can drive routing. Use that:
- Assign each rule a domain and configure domain-scoped notification routes (one channel per domain). This overrides a single noisy tenant-wide channel and is also the right bootstrap pattern when no ownership model exists yet.
- Route to groups, not individual user IDs: owners leave and IDs get disabled, breaking the chain. Use a service-account sender for outbound email.
- Tier your alert routing by urgency: for example, urgent rules notify on every failure, normal rules notify only after repeated failures, and low-priority rules stay dashboard-only with no push. Reserve channel broadcasts for portfolio-level health, not every rule.
- Prefer webhook-based integration with your ticketing system (for example, Jira, ServiceNow) over a native module; confirm current payload contents and autoassignment support in the product reference before designing the flow.
- Don't assume DQ status propagates automatically to downstream assets: confirm propagation behavior in the product reference, and regardless, avoid fanning a single failure out across every downstream asset (transforms make naive propagation misleading). For BI consumers who don't log into Atlan, prefer a custom-metadata status property or the browser extension (one table feeding 20 dashboards shouldn't fan out 20 alerts).
Trust scores: three different things get called "trust score"—the DQ pass/fail ratio across an asset's rules, the metadata completeness/health score (a catalog signal, not DQ), and a composite score. If you're unsure which one you're looking at, confirm the exact definition rather than guessing—especially before presenting it to leadership. For a computed, auditable, programmatically-aggregated trust score, build it in the metadata-lakehouse gold-layer DQ tables and query it in your BI layer, not the UI dashboard.
Common pitfalls
- Leading with coverage or rule-count metrics: a business audience responds to the reliability of the specific reports they own, not volume.
- Applying all AI-suggested rules unfiltered: noise dilutes trust.
- Starting with business-logic rules before foundational checks: slow, and it needs SME input you don't have yet.
- Running an enablement session without pre-identifying target assets: inconclusive.
- Routing alerts to individual user IDs or one tenant-wide channel: brittle and noisy.
- Assuming DQ scores propagate downstream automatically (they don't) or that DQS gates pipelines (it doesn't).
- Letting one blocked asset shut down a whole working session: pivot to another table and keep producing working rules.
- Scoping DQS onto work it can't own: it can monitor DQ within an MDM pipeline but can't own match/merge/survivorship; name that boundary explicitly.
- Speculating on a root cause for a generic sync error or a score-calculation question—route to support with the asset URL and a screenshot instead.
Troubleshooting
Rules execute natively in your warehouse and a background workflow syncs results back to Atlan on a short interval. A stalled or failed sync workflow is the single most common root cause of "results not updating," stale metrics, or a rule missing from the dashboard.
First moves:
- Results not updating / rule missing from dashboard → check the last successful result-sync run in the observability view before touching rules.
- Rules won't execute or won't schedule → confirm the service-role grants against the DQS setup docs.
- Generic or undiagnosable error → reproduce with a manual run, then open a support ticket with the tenant URL, connection name, asset URL, and an error screenshot. Don't speculate on root cause without engineering logs.
| Symptom | Likely cause | Action |
|---|---|---|
| Rules not executing | Missing/invalid DQ credentials | Validate credentials; re-run setup |
| Metrics not updating / stale results | Result-sync workflow halted | Verify the last successful sync timestamp; re-trigger or escalate |
| Rule missing from dashboard | Workflow sync issue | Validate the sync logs; re-run the workflow |
| Failed rule run | Warehouse compute timeout | Check cluster/warehouse sizing |
| Can't see which rows failed | — | Write a custom SQL rule that returns the failing keys; otherwise inspect in the source |
| "Failed to sync some rules" | Partial sync error | Open a ticket with the workflow run links; don't keep adding rules until it's resolved |
Schema changes behave differently by warehouse—a rule may silently stop executing or fail outright until remapped, so re-map and re-validate after a schema change. When a column type doesn't match the comparison a rule needs, cast inside a custom SQL rule rather than expecting a template rule to coerce types.
dbt statuses can mislead: a dbt model run can succeed (the SQL ran and the table materialized) while a dbt data test against that output fails—and both surface through the same "error"-style status. Distinguish which one failed before diagnosing. dbt results are surfaced read-only; rules you write natively execute in the warehouse, not in dbt.
A monitoring job running for many hours when it takes minutes usually means the query-history window is too large because runs are too infrequent—fix the cadence first (schedule frequently enough that each run is incremental), then open a ticket if it persists. (A multi-hour ingestion/full-load workflow is a connector problem, not a DQ cadence fix—route it to the connectors guide and keep the support ticket open.)
For the exact roles, grants, and warehouse objects DQS setup requires, follow the DQS setup docs. For which warehouses are GA versus in progress and current feature status, confirm in the product reference rather than relying on this guide.
Related
- Connectors and ingestion: assets must be crawled before you can monitor them; multi-hour ingestion workflows are a connector problem, not a DQ one.
- Lineage: confirm lineage before deciding rule placement; DQ status visibility depends on it.
- Metadata-lakehouse (gold-layer) docs—where to build a computed, auditable trust score.
- DQS setup docs: warehouse roles, grants, and setup steps.