Understand Tag Ingestion in the Unified Source Tags Model

Alation Cloud Service Applies to Alation Cloud Service instances of Alation

Customer Managed Applies to customer-managed instances of Alation

Applies from Alation version 2025.1.3

Once the unified source tags model is enabled on your instance, the next metadata extraction (MDE) from Snowflake or Databricks Unity Catalog data sources will bring the tags into the data catalog.

After metadata extraction, all tags become available as custom Picker fields under Admin Settings > Customize Catalog > Custom Fields, within the Pickers section.

Alation unifies tags across schemas and databases, but only if their definitions are structurally compatible. If the tag definitions aren’t compatible, Alation creates separate custom fields for those tags.

The compatibility factors include:

• Field name must match exactly (case-insensitive).

• Field type must match (single-select only).

• Certain fields are excluded (Status, Revision Status, multi-select pickers).

For example, if a tag INDUSTRY is defined in schema_A in Snowflake with values oil, tech, finance and in Databricks Unity Catalog with the value tech, the unified Picker field INDUSTRY in Alation will have values: oil, tech, finance, with the origin identified via icons or tooltips in the user interface. On the object catalog pages, the field tooltip provides schema-level context for Snowflake tags (schema_A.INDUSTRY); Databricks Unity Catalog tag origin is not displayed using the tooltip. Origin of a tag from Databricks Unity Catalog and Snowflake source is visible only on Customize Catalog page.

The following example shows Snowflake and Databricks icons next to the field values in Customize Catalog > Custom Fields, indicating the source of the tag values.

The following table summarizes the behaviour of unified tag Picker fields in Alation:

Element	What is Unified	What You See in Alation
Tag definition	Tags that have the same name across schemas or data sources (for example, Snowflake schema A and Databricks Unity Catalog)	If tag definitions share compatible allowed values, Alation creates a unified custom Picker field. If the allowed values differ across schemas separate fields are created. In both cases, the source or schema context is identified through icons and tooltips.
Allowed values in tags	The same allowed values associated with the tag.	All allowed values across schemas or data sources are displayed in the the Picker field dropdown. In the Customize Catalog page, source attribution is indicated in the user interface through a tooltip (for example, OIL in schema_A, FINANCE in Databricks Unity Catalog). There is no overlapping of semantically similar values unless they are identical strings. On object catalog pages, individual tag values do not display source attribution.
Applied values	Tag values that were auto-applied to Snowflake and Databricks objects or were manually applied as custom fields to objects from data sources where source tag extraction is not supported.	Applied tag values appear on the objects where they were applied. Example: INDUSTRY tag with value FINANCE is applied to a Snowflake table and also to a Databricks Unity Catalog table. If the same-name tag definitions share compatible values, they are shown in a single field. In the Customize Catalog page, the origin of each value is indicated via icons; on object catalog pages origin of individual values are not displayed. If the values are not compatible, the fields will be separate. Even if you later remove Databricks Unity Catalog objects from metadata extraction, the existing corresponding value on Snowflake will remain visible and unchanged. However, tag values extracted only from Databricks Unity Catalog will no longer appear on objects if you later remove Databricks Unity Catalog objects from metadata extraction.

Note

If fields are not unified due to incompatible definitions, Alation preserves the previously applied values on objects, and the fields remain separate. No applied tag data is lost during this process.

Understand Snowflake Tags Behavior within the Unified Source Tags Model

The following table outlines how the unified source tags model affects Snowflake tags.

Area	Impact on Snowflake Tags
Tag editability	Snowflake tag and value definitions cannot be edited in Alation. However, for Snowflake objects, users can assign or change the tag value on an object in the Alation UI (with relevant permissions). This triggers a sync to Snowflake. Tag name and allowed values cannot be edited in Alation. For non-Snowflake objects, any previously applied tag values are preserved and displayed on the object, even if those values are no longer part of the current source tag definition. However, such preserved values cannot be changed or reassigned via the Alation UI.
Scope of definition	As tags are defined at the schema level, different schemas can define the same tag name independently.
Behavior of allowed values	Allowed values are defined per schema. If tag definitions are structurally compatible (identical or non-conflicting overlapping allowed values), Alation merges values into one list. If they are incompatible, Alation treats them as separate fields per schema.
Tag picker behavior (during assignment)	In tag Pickers on an object, Alation displays the allowed values from the object’s source system. For example, if a tag is defined in multiple Snowflake schemas or sources, the Picker will only show values allowed in the current object’s context. Values applied from other sources may still be displayed on the object catalog page. However, if those values are no longer part of the current source, they cannot be newly assigned unless allowed for that object.
Syncing tags to the data source	Tag syncing is supported with constraints. The values are validated against Snowflake’s allowed list before the sync. Values dropped from the source are hidden from Pickers but are retained on objects where they were previously applied. Syncing to the source may fail if tag values are no longer valid. Tags from multiple schemas with the same name cannot be applied to an asset unless Snowflake itself has done so; this prevents sync ambiguity. Sync failures for invalid tag values may occur silently, as Alation does not provide realtime sync error feedback. Tag values that were dropped from Snowflake but are still applied remain visible but cannot be newly assigned or synced.
Impact on MDE	MDE schema selection and the Clean Up Source Tags toggle control visibility and retention of Snowflake tags in the catalog. For information on the Clean Up Source Tags toggle, see Snowflake.

Note

In Snowflake environments with multiple schemas, it is possible to see multiple same-name tag fields in Alation if their definitions are incompatible across schemas. This is a known behavior, designed to preserve semantic integrity and avoid sync issues.

Important

• With the unified source tags model enabled, there is no support for the alation.feature_flags.enable_snowflake_tag_filtering_by_schema flag. This flag was used to eliminate duplicate tags and is now redundant. This means that tags applied at source in one schema will now appear on assets in other schemas if the tag was applied to those assets, regardless of which schema defined the tag. This behavior aligns with Snowflake’s design and is now the default. For example, if the RATING tag with a value HIGH was defined in schema_A but applied to a table in schema_B, the tag will now appear on the schema_B table even though it was not defined in schema_B.

• The unified source tags model will continue to support the tags such as PRIVACY_CATEGORY and SEMANTIC_CATEGORY under the Snowflake-specific SYSTEM.CORE schema. Alation doesn’t extract SYSTEM.CORE schema; however, these tags will be extracted if they are applied across various database objects.

Consider the following use cases:

1. Tag name, tag values, and Snowflake data source are all the same

   Consider a tag, INDUSTRY, with values oil, tech defined in schema_A and schema_B in the same Snowflake data source.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech.

2. Tag name and Snowflake data source are same with partially overlapping tag values

   Consider a tag, INDUSTRY, with values oil, tech in schema_A, and tech, finance in schema_B in the same Snowflake source.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech, finance

3. Same tag name and tag values across different Snowflake data sources

   Consider a tag, INDUSTRY, with values oil, tech in schema_A in Snowflake source1 and in schema_B in Snowflake source2

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech

4. Same tag name across different data sources with partially overlapping values

   Consider a tag, INDUSTRY, with values oil, tech in schema_A in Snowflake source1, and tech, finance in schema_B in Snowflake source2.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech, finance

   If sources are different (different JDBC URLs), and there is no known incompatibility, the model allows unification across sources (even if values are partially overlapping) because there is no risk of sync ambiguity (sync happens per-source).

5. Tag name and Snowflake source are same but with different or overlapping values

   Consider a tag, UNIFIED_TAG01, with values valueA, valueB, valueC in a schemaWithTags schema, and valueB, valueC, valueD in schemaWithTags2 schema in the same Snowflake source.

   Post unification: The tag UNIFIED_TAG01 is unified into one custom Picker field with values: valueA, valueB, valueC, and valueD

   

   However, on the object catalog page, the allowed values for schemaWithTags will only be valueA, valueB, valueC and for schemaWithTags2 will be valueB, valueC, valueD

   

6. Tag name is same across different sources with completely different values

   Consider a tag, INDUSTRY, with values oil, tech in schema_A in Snowflake source1, and finance, HR in schema_B in Snowflake source2.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech, finance, and HR

7. Different tag names with same values in same or different sources

   Consider a tag, INDUSTRY, with values finance and HR in schema_A and a tag, DEPARTMENT,in schema_B with values finance, HR in the same Snowflake source.

   Post unification: Results in two separate custom Picker fields: INDUSTRY and DEPARTMENT with values: finance, HR

8. Tag name is same but uses different case (upper or lower case)

   Consider a tag, INDUSTRY, with values finance and HR in schema_A and a tag, industry, in schema_B with values finance, HR in the same Snowflake source. Metadata extraction is first run on schema_A.

   Note

   The results remain the same for tags within same source or across different sources.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech, finance, and HR

   If the metadata extraction was first run on schema_B, the tag industry would be unified into one custom Picker field with values: oil, tech, finance, and HR

9. Tag name is same across different sources with values defined in different cases (upper or lower case)

   Consider a tag, INDUSTRY, with values finance and HR in schema_A in Snowflake source1, and INDUSTRY, in schema_B with values Finance, hr in Snowflake source2. Metadata extraction is first run on schema_A.

   Note

   The results remain the same for tags within same source or across different sources.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: finance, HR

   If the metadata extraction was first run on schema_B, the tag INDUSTRY would be unified into one custom Picker field with values: Finance, hr

Note

The unification results remain the same if the data sources are same or different. For example, from different Snowflake sources: source1 and source2 OR different sources such as Snowflake and Databricks Unity Catalog sources.

Understand Databricks Unity Catalog Tags Behavior with Unified Source Tags Model

Databricks Unity Catalog tags are treated as key-value pairs. If the tag key matches an Alation custom Picker field, values are included in that field; otherwise, a new read-only field is created.

Extracting tags from Databricks Unity Catalog requires the unified source tags model to be enabled. If you want these tags to appear in the catalog, this feature must be turned on. If the feature flag is disabled, Databricks Unity Catalog tags are not extracted or shown anywhere in Alation (including catalog pages, search facets, or custom field settings) and no background extraction jobs are triggered.

Note

If you have defined a tag with only a key and no value, Alation displays an empty value and the Databricks icon next to it in the corresponding Picker field editor under the Admin Settings > Customize Catalog > Custom Fields > Pickers section as is shown below:

You will notice the following Databricks Unity Catalog tag behavior in Alation when the feature flag is enabled (Enable Unified Source Tags Model):

• Alation displays the Databricks Unity Catalog tags in the unified field list.

• They are read-only and cannot be edited.

• If a tag value appears from both Snowflake and Databricks Unity Catalog, both origins are indicated with icons on the Customize Catalog > Custom Fields page.

Note

Tags applied at the catalog level in Databricks Unity Catalog are extracted and visible on the Custom Fields page (Admin Settings > Customize Catalog > Custom Fields > Pickers) but aren’t automatically linked to catalog objects in Alation. You can assign these fields to the schema or table object templates after extracting them.

The following table outlines how the unified source tags model affects Databricks Unity Catalog tags:

Area	Impact on Snowflake Tags
Tag editability	Databricks Unity Catalog tags are read-only in Alation.
Scope of definition	Tags can be defined at various levels such as catalog, schema, table, and column.
Behavior of allowed values	Allowed values are defined once per Databricks Unity Catalog tag key. Alation imports and displays them under the unified custom field when this field is created.
Syncing tags to the data source	Not supported. Databricks Unity Catalog tags are read-only in Alation.
Impact on MDE	If Databricks Unity Catalog tags are deleted in the source system and the Clean Up Source Tags toggle is ON, those tags will be deleted from the Alation catalog. For Unity Catalog, tag deletion is not driven by schema selection, but by changes in the source system or deselection of specific assets during metadata extraction. For information on the Clean Up Source Tags toggle, see Databricks Unity Catalog
Displaying tag values in Alation	Applied values appear in the unified custom Picker field as read-only, and identified using the tooltip on the catalog page and icons in the Customize Catalog > Custom Fields > Pickers section. In tag dropdowns during editing or assignment, Databricks Unity Catalog tag values appear in a flat list with no icons or tooltips to indicate their origin.

Note

In custom Pickers field on an object, Alation scopes allowed values to the object’s source system. For example, if a tag is defined in both Snowflake and Databricks Unity Catalog, the picker will only show the values allowed for that specific object’s source system. Applied values from other systems may still appear on the object catalog page but cannot be newly assigned unless allowed for that object.

Understand Cross-Source Tags Behavior

When multiple data sources define a tag with the same name (for example, INDUSTRY), Alation creates a single unified custom field, even if those sources are entirely separate (for example, data sources of the same type with different JDBC URIs or Snowflake accounts).

In the Picker dropdown during tag assignment or editing, the allowed values shown are scoped to the object’s source system. On the catalog object’s page (field read view), all applied values are displayed, regardless of source system. This ensures users only see values that are meaningful in the context of the source system.

Example:

The Alation catalog has the following distinct data sources:

• The source1 from Snowflake defines the INDUSTRY tag with values: OIL, TECH

• The source2 from Databricks Unity Catalog defines the INDUSTRY tag with values: INSURANCE, HEALTHCARE

After tag unification, Alation creates a single custom field called INDUSTRY with the following unified allowed values: OIL (source1), TECH (source1), INSURANCE (source2), HEALTHCARE (source2)

However, in a table from the source1 data source, the picker for INDUSTRY will only display the values: OIL and TECH and in a table from the source2 data source, the picker will display the values: INSURANCE and HEALTHCARE.

In the tag dropdown during editing or assignment, values appear in a flat list with no icons or tooltips to indicate their source system. Icons and tooltips are only shown in Customize Catalog and in field tooltips on the catalog object’s page.

Consider the following use cases :

1. Tag and custom field Picker in Alation with same name and values

   Consider a tag, INDUSTRY, with values oil, tech defined on schema_A in a Snowflake data source and an INDUSTRY picker field in Alation with the same values.

   Post unification: The tag INDUSTRY is unified into one custom Picker field with values: oil, tech.

2. Tag and custom field Picker in Alation with overlapping values

   Consider a tag, INDUSTRY, with values tech, finance and a custom field Picker in Alation INDUSTRY with values oil, tech;

   Post unification: The tag INDUSTRY is unified into one custom field Picker with values: tech, finance. The unified tag displays the values coming from a data source (source-specific values) including the ones from the custom field Picker in Alation on the Custom Fields page (Admin Settings > Customize Catalog > Custom Fields > Pickers). The other values in the custom field Picker in Alation (oil), however, are retained in the catalog pages where they are applied.

Understand the Renaming Behavior of Unified Source Tags

When a tag is renamed at the data source (for example, in Snowflake), the next metadata extraction reflects the change in Alation.

Note

This applies only when the tag is renamed in the source system (e.g., Snowflake), not on the Customize Catalog page in Alation.

For example, let’s assume that a Snowflake schema defines a tag DEPARTMENT with values: SALES, MARKETING. This tag is applied to several objects, including:

• The customer_contacts.name table: DEPARTMENT with value SALES

• The ad_campaigns.summary table: DEPARTMENT with value MARKETING

Later, the Snowflake admin renames the tag from DEPARTMENT to DIVISION on Snowflake.

When the Source Admin runs the next metadata extraction in Alation with the schema selection unchanged and the Clean Up Source Tags toggle turned off, then:

• The tag DEPARTMENT and all its tag links are deleted.

• A new custom field DIVISION is created to represent this tag.