## Data Quality Studio setup reference (Snowflake)

URL: https://docs.atlan.com/product/capabilities/governance/data-quality/references/dq-studio-snowflake-setup

> The Snowflake-side setup facts for Data Quality Studio—roles, grants, the ATLAN_DQ database, warehouse scope, scheduling constraints, execution model, and connector coverage status.

# Data Quality Studio setup reference (Snowflake)

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:**
 ```sql
 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 `.
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](https://docs.atlan.com/llms/platform/get-started/feature-maturity-matrix/llms.txt) 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](https://docs.atlan.com/llms/platform/get-started/feature-maturity-matrix/llms.txt) 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:

```sql
GRANT USAGE ON DATABASE "" TO ROLE "";
GRANT USAGE ON SCHEMA ""."" TO ROLE "";
GRANT REFERENCES ON TABLE "".""."" TO 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:

```sql
SHOW DATABASES LIKE 'ATLAN_DQ'; -- DQ database exists
USE 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](https://docs.atlan.com/llms/platform/get-started/feature-maturity-matrix/llms.txt): DQS roadmap items (per-rule schedules/routing, composite-key uniqueness, rule versioning UI, anomaly detection, BigQuery GA).
- [Data quality best practices](https://docs.atlan.com/llms/governance/data-quality/plan-and-run-data-quality/llms.txt): 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.

---