Snowflake

Data LineageER DiagramsAI AutodocumentationData-based Data ClassificationSchema Change TrackingData QualityData ProfilingForeign Key TestingReference DataMetadata SyncScheduling tasksExtended PropertiesExecution Flows

Specification

Imported metadata

	Imported	Editable
Tables, Transient tables
Columns
Data types
Nullability
Column comments
Table comments
Foreign keys
Primary keys
Unique keys
External tables, Iceberg tables
Location
Script
Columns
Data types
Nullability
Column comments
Table comments
Foreign keys
Primary keys
Views, Materialized Views
Script
Columns
Data types
Column comments
View comments
Dynamic tables
Script
Columns
Data types
Column comments
Table comments
Stored procedures
Script
Parameters
Procedure comments
Tasks
Script
Task comments
User-defined Functions
Script
Input arguments (all as a single field)
Output results (as a single field)
Function comments
Stages
Location
Stage comments
Pipelines
Script
Pipeline comments
Sequences
Streams
Columns
Script
Shared metadata
Dependencies
Created time
Last updated time
URL

Comments

Dataedo reads comments from the following Snowflake objects:

Object	Read	Write back
Tables, Transient tables
Column comments
External tables, Iceberg tables
Column comments
Views, Materialized Views
Columns
Dynamic tables
Columns
Stored procedures
Tasks
User-defined Functions
Stages
Pipelines

Data profiling

Dataedo supports the following data profiling in Snowflake:

Profile	Support
Table row count
Table sample data
Column distribution (unique, non-unique, null, empty values)
Min, max values
Average
Variance
Standard deviation
Min-max span
Number of distinct values
Top 10/100/1000 values
10 random values

Data Quality

You can check whether data in Snowflake tables is accurate, consistent, complete, and reliable using Data Quality functionality. Data Quality requires SELECT permission over the tested object.

Data Lineage

Source	Method	Status
Views - object level	From dependencies
Views - object level	From SQL parsing
Views - column level	From SQL parsing
Dynamic tables - object level	From INFORMATION_SCHEMA
Dynamic tables - column level	From SQL parsing
External storage (Azure, AWS) -> Stages	From INFORMATION_SCHEMA
Stages -> External tables (Azure, AWS)	From INFORMATION_SCHEMA
Stages -> Pipelines	From SQL parsing
Pipelines -> Tables	From SQL parsing
Stages -> Tables (COPY INTO)	From ACCOUNT_USAGE
Table/View -> Streams	From ACCOUNT_USAGE
Tables, Views - column level	From GET_LINEAGE
dbt	dbt connector
Tables - from Kafka	TBD	TBD

Column-level data lineage is retrieved using the Dataedo SQL parser. Read more about the capabilities of Snowflake SQL parser.

Read more about Dataedo Snowflake data lineage.

Data Classification

Dataedo can use the following information to carry out automated Data Classification on your Snowflake assets:

• schema information
• sample column data (if enabled)

Metadata Sync

Metadata Sync is supported as well. Dataedo creates a two-way mapping between Data Classification and Snowflake's tag references (write-back requires additional privileges).

On Snowflake, a Dataedo Classification becomes a tag object set on a column: the classification is the fully qualified tag name and the sensitivity level is the tag value.

Dataedo only ever sets and clears tag values — it never runs CREATE TAG. The tags therefore have to exist in Snowflake before a mapping can point at them, so set the Snowflake side up first and mirror it in Dataedo afterwards.

At a glance

Dataedo	Snowflake
Classification (e.g. CCPA)	Tag object, fully qualified: TAGS.PUBLIC.CCPA
Sensitivity level (e.g. Personal Information)	Tag value (a string, e.g. 'Personal Information')
Column has classification CCPA = Personal Information	Column has tag TAGS.PUBLIC.CCPA = 'Personal Information'
Classification removed from the column, or never assigned	Tag unset on the column (UNSET TAG "TAGS"."PUBLIC"."CCPA") — the tag object itself stays, only the column association is dropped
Scope	Columns of tables (including external and Iceberg tables) and views (including materialized views and dynamic tables) in the connected database

Prerequisites

• Read — Dataedo reads tags through INFORMATION_SCHEMA.TAG_REFERENCES_ALL_COLUMNS for each documented table and view. It returns tags on objects the role can already see, so it needs no privilege beyond those the import already requires — in particular, none of the ACCOUNT_USAGE grants listed for lineage and dependencies. Tags are read live, without the ACCOUNT_USAGE latency.
• Write — Dataedo runs ALTER TABLE|VIEW … ALTER COLUMN … SET TAG / UNSET TAG, which requires the global APPLY TAG privilege, or OWNERSHIP of the object together with APPLY on the tag.

The full statement list for every connector is in Metadata Sync → Executors.

Setting up Data Classification

Step 1. Create the tags in Snowflake

Create one tag per classification, with ALLOWED_VALUES listing exactly the values you intend to map to sensitivity levels. In this example we will create a CCPA tag with two allowed values (Personal InformationandN/A`):

CREATE TAG TAGS.PUBLIC.CCPA
  ALLOWED_VALUES 'Personal Information', 'N/A';

In Snowsight, you can review the result under Governance & security → Tags. A tag holds the two things the Dataedo mapping will need:

• [A] — the tag name (in this caseCCPA) together with its Location (TAGS / PUBLIC). The two together form the fully qualified tag (here:TAGS.PUBLIC.CCPA). This fully equipped tag is what you will need to type into Dataedo.
• [B] — the Allowed Values list, one entry per sensitivity level.

useful tip

ALLOWED_VALUES is optional, but worth declaring. Dataedo works with any Snowflake tag. Listing the allowed values buys you validation at the source: Snowflake then rejects a tag applied by hand with a typo, instead of letting it reach Dataedo as an unmapped value that blocks the column. It also keeps the setup honest — the allowed values and the Dataedo level mapping are the same list, and keeping the two identical is the whole configuration.

Step 2. Map the classifications in Dataedo

Open the data source, go to Metadata Sync → Manage Classification Mapping and select the classifications to synchronize. The popup you see has the following fields:

• [A] — checkboxes, used to select Classifications you want to sync.
• [B] — Mapped Tag Name: the fully qualified tag, in DATABASE.SCHEMA.TAG_NAME form, which you should take from the tag's Location as explained in Step 1. Malformed names (not following the three-part pattern) will be rejected, and you will not be able to proceed.
• [C] — the level rows: each Dataedo sensitivity level and the tag value it becomes. These should match the tag's Allowed Values one for one.

Once you get past this step, you can follow regular Metadata Sync Configuration.

Good to know

• Only tags whose name is mapped are read. Any other column tag in Snowflake is ignored and never touched. Several classifications on one column are fine — each one becomes its own tag.

• Type the tag name in the exact case Snowflake stores it — usually UPPERCASE. Snowflake stores unquoted identifiers in upper case, so create tag public.ccpa creates PUBLIC.CCPA, while Dataedo treats every part of Mapped Tag Name as a quoted, case-preserving identifier ("DB"."SCH"."TAG"). That tag has to be mapped as TAGS.PUBLIC.CCPA; typed as tags.public.ccpa it names a different tag that does not exist — the export then fails for every column with a "tag does not exist or not authorized" error, and the import never matches the source tag either. Only a tag created with quoted lower case (create tag "public"."ccpa") is mapped in lower case.

• Tag values are case-sensitive as well: 'Personal Information' and 'personal information' are two different values.

• The mapping field wants the tag's own database, not the documented one. A governance tag living in another database is fine, as long as the role has APPLY on it.

• The mapping is not checked against the tag's ALLOWED_VALUES when you save it. A mapped value outside the list fails only at sync time, per column, as an error row in Sync History. Copy the allowed values into the mapping modal 1:1, same spelling and same case.

• Object limits. Snowflake allows at most 50 tags per object, and 50 distinct tags across the columns of one table. Mapping more than 50 classifications would reach the second limit on any table that uses them all.

• The tag name must be unique across mapped classifications; the modal rejects duplicates.

• Within one classification, each level needs its own tag value. The modal rejects two levels mapped to the same value, because when Dataedo reads that value back from Snowflake it cannot tell which level to assign.

The rules that hold for every connector — blocked mapping gaps, Dry Run, and when writes actually happen — are described under Classification sync rules.

Known limitations

• Some features (object dependencies, COPY INTO lineage, stream columns) require access to SNOWFLAKE.ACCOUNT_USAGE views, which need additional grants beyond the default role. See Required Permissions for details.

Due to Snowflake Connector for .NET limitations:

• username and password
  • cannot contain ; or = characters
• database, role and warehouse name
  • cannot contain ;, ' or \ characters

If one schema contains more than:

• 5000 foreign keys
• 6000 unique keys
• 10 000 primary keys

then Dataedo will read those keys per object, not per schema — this will result in a longer import time.

Dataedo classification sync is column-level only:

• tags on tables or views are not synced
• classification on objects other than tables or views (for example, procedures) is not synced

Learn more

Connect to Snowflake

Data Lineage from Snowflake

Snowflake Enterprise Connector