Data Quality Studio setup reference (Snowflake)

||Connect docs via MCP

The warehouse-side facts required to stand up Data Quality Studio (DQS) on Snowflake, plus its scheduling and execution constraints and current connector coverage. Rule-design and rollout guidance lives in the data-quality best-practices guide.

Setup sequence

Crawl Snowflake assets → run the DQS Snowflake setup (roles, database objects, grants) → enable in Atlan (Admin → Labs → Data Quality) → create rules → create a schedule.

• Complete all warehouse-side prerequisites before enabling DQ in Atlan.
• After enabling, wait up to ~20 minutes for the Data Quality tab to appear in Atlan.

Prerequisites

• Snowflake account-admin access for setup.
• One DQS connection per tenant: multi-connection isn't available.
• A dedicated DQ warehouse.
• DQS uses separate credentials from the metadata crawler (the same host/URL can be reused; private-link setups can often reuse the existing connection).
• A dedicated DQ database is strongly recommended—isolation, simpler permissions, no conflict with application data; minimal storage/compute footprint.

Roles, objects, and grants (Snowflake side)

Setup creates a dedicated DQ database family: ATLAN_DQ + ATLAN_DQ_SHARED; these names are hardcoded (renaming requires editing the stored procedures, not recommended): with SHARED / DMFS schemas, a DQ admin role (DQ_ADMIN), an Atlan service role (ATLAN_DQ_SERVICE_ROLE), a service user, and the MANAGE_DMF secure procedure. Representative steps (confirm current values at docs.atlan.com → data-quality/snowflake/how-tos/set-up-snowflake):

1. Initialize variables: DQ user, DQ database, DQ warehouse, DQ_ADMIN, ATLAN_DQ_SERVICE_ROLE, the .SHARED / .DMFS schemas, the MANAGE_DMF procedure path.
2. Create roles + warehouse access: create DQ_ADMIN and ATLAN_DQ_SERVICE_ROLE; grant each OPERATE, USAGE on the DQ warehouse.
3. Create the user and assign the service role.
4. Create the database and the .SHARED + .DMFS schemas.
5. Create the MANAGE_DMF stored procedure (secure procedure managing Snowflake Data Metric Functions).
6. Grant ownership of the DQ database, both schemas, and MANAGE_DMF to DQ_ADMIN.
7. Grant Snowflake system roles:

   GRANT DATABASE ROLE SNOWFLAKE.DATA_METRIC_USER TO ROLE DQ_ADMIN;
   GRANT APPLICATION ROLE SNOWFLAKE.DATA_QUALITY_MONITORING_VIEWER TO ROLE ATLAN_DQ_SERVICE_ROLE;
   GRANT DATABASE ROLE SNOWFLAKE.DATA_METRIC_USER TO ROLE ATLAN_DQ_SERVICE_ROLE;
   GRANT EXECUTE TASK ON ACCOUNT TO ROLE ATLAN_DQ_SERVICE_ROLE;
   GRANT EXECUTE MANAGED TASK ON ACCOUNT TO ROLE ATLAN_DQ_SERVICE_ROLE;

8. Grant usage + future grants to the service role: USAGE on the DQ database and both schemas, plus USAGE ON FUTURE FUNCTIONS IN SCHEMA <DMFS>.
9. Grant access to the target data (each database/schema to be monitored): USAGE on the database and schemas, and REFERENCES on all and future tables and views—to the service role.

Enablement (what happens inside Atlan)

Admin → Labs → Data Quality → enable → configure the connection. A cron workflow then creates CORE and STORE schemas on the DQ warehouse and the persistence tables:

Table	Purpose
DQ_RULE	Rule definitions, versioned via IS_CURRENT / VALID_FROM / VALID_TO
DQ_RULE_RESULT	Rule outcomes
DQ_RUN_SCHEDULE	Scheduling metadata

The DQ database name entered in Atlan must match Snowflake exactly—it's case-sensitive. After you enter the DQ configuration, the UI validates it; a success message means prerequisites are met and DQ can be enabled on specific assets.

Execution and sync model

• Rules execute natively in the warehouse: Snowflake via Data Metric Functions and stored procedures; Databricks via serverless jobs. No raw data leaves the warehouse; Atlan stores only rule definitions and results.
• Results are written to DQ_RULE_RESULT; a result-fetch workflow syncs them to Atlan every ~5 minutes. A setup workflow runs at enablement and daily at 12 AM IST. A stalled result-fetch workflow is the most common cause of "results not updating"—check its last successful run before touching rules.
• On rule create/update/delete, a change-data-capture event pushes the change to the source warehouse.
• Rules consume warehouse compute: scan scope and cadence directly drive cost.

Scheduling constraints

• A single schedule applies to all rules on the connection/asset: per-rule schedules aren't available (roadmap).
• The DQ schedule is independent of metadata-crawl workflows.
• Scheduled runs autoexecute; manual on-demand ("run now") is available for custom SQL rules only (template-rule manual run is planned).
• The run-now API supports externally triggered execution (for example, business-days-only or CI/CD-triggered runs).

Supported entity types (Snowflake)

Supported	Not supported
Table, View, Materialized View, External Table, Iceberg Table	Secure View, Pipes, Streams, Stages, UDFs, Dynamic Tables

Schema-change behavior

• Snowflake: after a schema change the rule remains but silently stops executing: re-map/re-validate it.
• Databricks: the rule fails until remapped.
• Automated rule repair on schema change is roadmap, not available today.

Connector coverage status

See the feature maturity matrix for the authoritative snapshot. Summary as of 2026-07-08:

• Snowflake—GA (see the Setup sequence and Roles, objects, and grants sections earlier in this page).
• Databricks—parity in progress; see the feature maturity matrix for current GA status. DQS on Databricks needs only read/SELECT (query) access on source—never write/edit. An existing crawl connection usually satisfies the DQ runtime; verify before requesting new production access.
• BigQuery—not GA (Data Transfer Service–based). Known setup constraints: the DQS Project ID must be a valid GCP project ID (6–63 lowercase letters/digits/dashes—for example, cbh-atlan-dqs, not ATLAN_DQ); the DQS Dataset field takes the dataset name only (dq_collection, not ATLAN_DQ.dq_collection); the service account needs bigquery.jobs.create, datasets.create, tables.create, and dataEditor on the DQ dataset; the DTS API (bigquerydatatransfer.googleapis.com) must be enabled. After correcting the environment config, scheduled queries must be re-registered via the asset's Data Quality tab → Schedule config → "Sync again."
• dbt: dbt test results are surfaced read-only; push-down rule creation is native to Snowflake/Databricks, not dbt.

Permission-error fixes

If rules fail to execute or schedule, confirm these grants exist for the service role:

GRANT USAGE ON DATABASE "<DB_NAME>" TO ROLE "<ATLAN_DQ_SERVICE_ROLE>";
GRANT USAGE ON SCHEMA "<DB_NAME>"."<SCHEMA_NAME>" TO ROLE "<ATLAN_DQ_SERVICE_ROLE>";
GRANT REFERENCES ON TABLE "<DB_NAME>"."<SCHEMA_NAME>"."<TABLE_NAME>" TO ROLE "<ATLAN_DQ_SERVICE_ROLE>";

"DQ database doesn't exist or isn't authorized" → either the DQ database wasn't created or the connection role lacks permission. Verify with:

SHOW DATABASES LIKE 'ATLAN_DQ';        -- DQ database exists
USE ROLE <YOUR_CONNECTION_ROLE>;
USE DATABASE ATLAN_DQ;                  -- role access works

Alerting and rule-asset facts

• DQ rules are first-class assets: they carry an owner, tags, domains, a README, and a webhook.
• Notification routing is configurable at the domain level (one channel per domain). Per-rule notification routing isn't available (roadmap); the interim mechanism is a per-rule webhook whose payload carries the asset ID and the failed query.
• DQ scores don't autopropagate downstream through lineage by design.

Related

• Feature maturity matrix: DQS roadmap items (per-rule schedules/routing, composite-key uniqueness, rule versioning UI, anomaly detection, BigQuery GA).
• Data quality best practices: which rules to build first, DQS vs dbt/observability tools, alert-noise design.
• Setup how-to: docs.atlan.com → data-quality/snowflake/how-tos/set-up-snowflake.