> For the complete documentation index, see [llms.txt](https://docs.seemoredata.io/external-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.seemoredata.io/external-docs/fundamentals/settings/tags-management.md).

# Tags Management

## Overview

The **Tags Management** system lets you define tags that Seemore uses to classify queries and Snowflake objects (databases, schemas, tables, warehouses, dashboards, and more). Once tagged, data across Seemore — cost views, observability screens, and the Query Analyzer — can be filtered and grouped by tag.

There are three types of tags in Seemore:

| Type                     | Source                                                                                                                     | Who manages it                 |
| ------------------------ | -------------------------------------------------------------------------------------------------------------------------- | ------------------------------ |
| **Snowflake (imported)** | Native Snowflake object tags, synced automatically                                                                         | Read-only in Seemore           |
| **Query**                | Built-in extractors that read Snowflake `QUERY_TAG` and query comments for known integrations (dbt, Tableau, Looker, etc.) | Managed by Seemore — read-only |
| **Custom**               | User-defined rules that match queries or objects based on conditions                                                       | Editors and above              |

{% hint style="info" %}
Accessing Tags Management requires the **tags-management** feature flag to be enabled for your account. Contact your Seemore account team if you don't see it in the navigation.
{% endhint %}

***

## Navigating Tags Management

Go to **Tags Management** in the left navigation bar. The page is organized into four tabs:

* **All** — a combined view of every tag across all types.
* **Snowflake** — imported native Snowflake tags (read-only).
* **Query** — tags extracted from query history.
* **Custom** — user-defined tags with configurable rules.

Use the search bar to filter by tag name.

***

## Snowflake (Imported) Tags

These tags come directly from your Snowflake account's native tag definitions. Seemore syncs them automatically during metadata imports.

* **No action is required** — they appear in Seemore as soon as they exist in Snowflake.
* They are **read-only** in Seemore; create, edit, and delete operations are handled in Snowflake.
* They appear in cost and observability views wherever Snowflake assets are tagged.

***

## Query Tags

Query tags are key-value metadata that Seemore **automatically extracts from your Snowflake queries** — no configuration required. Each time a query runs, Seemore inspects the SQL comments and the Snowflake `QUERY_TAG` property to identify which tool or pipeline issued it and attaches structured tags to the query record.

Seemore ships with built-in extractors for the most common integrations. Tags appear in the format `Integration.TagName` (e.g. `DBT.NodeName`, `Tableau.WorkbookLuid`).

| Integration     | Example tags                                                 |
| --------------- | ------------------------------------------------------------ |
| **dbt**         | `NodeName`, `NodeSchema`, `NodeDatabase`, `CloudJobId`       |
| **Tableau**     | `WorkbookLuid`, `DashboardLuid`, `WorksheetLuid`, `UserLuid` |
| **Looker**      | `UserId`, `InstanceSlug`                                     |
| **Power BI**    | `Host`, `HostContext`, `PowerQuery`                          |
| **Airflow**     | `DagId`                                                      |
| **Hex**         | `ProjectId`, `ProjectName`, `UserEmail`                      |
| **ThoughtSpot** | `type`, `task`, `isRLSApplied`                               |

In addition, every matched query receives a special **Integration** tag identifying which tool issued it (e.g. `Tableau`, `Looker`, `DBT`).

Use the **Query** tab in Tags Management to browse all query tags currently available in your account. The tags listed here are populated automatically as queries flow through Seemore — there is nothing to configure.

For a deeper look at where query tags can be used (filtering Workloads, grouping costs, scoping Domains), see [Query Tags](/external-docs/fundamentals/our-features/observability/query-tags.md).

{% hint style="info" %}
Don't see your tool listed, or need to extract a custom `QUERY_TAG` value or SQL-comment field? You can define your own rules using [Custom Tags](#custom-tags) below.
{% endhint %}

***

## Custom Tags

Custom tags are fully user-defined. You write rules that tell Seemore how to derive a tag value — either from your **query history** or from properties of your **Snowflake objects** (databases, schemas, tables, compute units, users, functions).

{% hint style="warning" %}
Creating, editing, and deleting Custom tags requires the **Editor** role or higher.
{% endhint %}

### Starting a new custom tag

1. Open the **Custom** tab and click **New Tag**.
2. Enter a **tag name** — this is how the tag will appear in filters and group-by selectors across Seemore.
3. Choose the source you want to extract the value from:
   * **Extract from Queries** — derive the value from a query-history field.
   * **Extract from Objects** — derive the value from properties of Snowflake assets.
4. Define the rules (see the two sections below).
5. Click **Save**. Seemore immediately triggers a backfill/association run so the tag appears on existing data within minutes.

***

### Creating a query custom tag

Use this mode when you want to attach a tag value to **queries** based on something inside the query history — for example, the database the query writes to, a field embedded in the Snowflake `QUERY_TAG`, or a JSON value inside a SQL block-comment footer.

#### Step 1 — Choose what to extract

Pick **one** extractor from the list. Seemore reads that field from every query and uses the result as the tag value.

| Extractor           | What it reads                                                                   | Notes                          |
| ------------------- | ------------------------------------------------------------------------------- | ------------------------------ |
| **Database name**   | The database of the query's destination table; falls back to the source table   | Multi-rule                     |
| **Schema name**     | The schema of the destination table; falls back to the source table             | Multi-rule                     |
| **Table name**      | The destination table name; falls back to the source table                      | Multi-rule                     |
| **Query tag field** | The Snowflake `QUERY_TAG` set on the session/query                              | Supports an optional JSON path |
| **Query comment**   | The query text itself, or a JSON value inside the trailing block-comment footer | Supports an optional JSON path |
| **User**            | The Snowflake user who ran the query                                            |                                |
| **Compute unit**    | The compute unit (infra group) the query ran on                                 |                                |
| **Query type**      | The Snowflake query type (e.g. `SELECT`, `INSERT`, `MERGE`)                     |                                |

{% hint style="info" %}
**Multi-rule extractors** (Database/Schema/Table name) automatically write **two rules** under the hood — one for the destination table and one for the source tables — so a single tag covers both reads and writes.
{% endhint %}

#### Step 2 — Optionally narrow with a JSON path

For **Query tag field** and **Query comment**, you can extract a single value out of a JSON payload using dot notation (e.g. `user.id`).

* For **Query tag field**, the path is rooted at the parsed `QUERY_TAG` object.
* For **Query comment**, the path is rooted at the JSON object found inside the query's trailing block-comment footer.

Leave the path empty to use the entire value as-is.

#### Step 3 — Save

On save, Seemore stores the tag and triggers a **7-day backfill** over recent query history so the tag appears on past data, then continues to apply the rule to all new queries as they're processed.

***

### Creating an object custom tag

Use this mode when you want to attach a tag value to **Snowflake assets** based on their name — for example, tagging everything in databases that start with `PROD_` as `environment = PROD`.

A custom object tag is built from one or more **rules**. Each rule has the shape:

> **WHERE** *asset matches one or more conditions*   **TAG AS** *value*

#### Step 1 — Define the conditions

Inside a rule, add one or more conditions. Each condition has three parts:

| Part           | Options                                                          |
| -------------- | ---------------------------------------------------------------- |
| **Asset type** | Databases · Schemas · Tables · Compute units · Users · Functions |
| **Operator**   | Equals · Contains · Starts with · Ends with                      |
| **Value**      | The string to match against the asset's name                     |

The first condition is labeled **WHERE**; additional conditions in the same rule are labeled **OR** — any matching condition will cause the rule to fire.

{% hint style="info" %}
Conditions match on the **asset's name**. So `Databases · Starts with · PROD_` matches every database whose name begins with `PROD_`.
{% endhint %}

#### Step 2 — Assign the tag value

Fill the **TAG AS** field with the value that should be assigned when any condition in the rule matches. Example: `PROD`.

#### Step 3 — Add more rules (optional)

Click **Add rule** to define another rule with its own conditions and its own **TAG AS** value. This is how you create a multi-value tag — for example, one tag named `environment` with three rules producing `PROD`, `STAGING`, and `DEV`.

A simple example:

| Rule | Conditions                                                             | TAG AS    |
| ---- | ---------------------------------------------------------------------- | --------- |
| 1    | Databases · Starts with · `PROD_`  OR  Schemas · Contains · `_prod_`   | `PROD`    |
| 2    | Databases · Starts with · `STG_`                                       | `STAGING` |
| 3    | Databases · Starts with · `DEV_`  OR  Databases · Contains · `sandbox` | `DEV`     |

#### Step 4 — Save

On save, Seemore evaluates every rule against your existing assets, writes the tag-to-asset mapping, and removes any obsolete mappings from a previous version of the tag. The same evaluation runs again automatically on every metadata import so newly-added assets get tagged as they arrive.

***

### Editing a custom tag

Click the **edit** icon on any row in the Custom tab. The same form opens pre-populated with the current rules. Saving **replaces all rules** for that tag and re-runs association — there is no rule-level edit history.

### Deleting a custom tag

Click the **delete** icon on a Custom tag row. This permanently removes:

* The tag definition.
* All query rules associated with the tag (for query custom tags).
* All object rules and their conditions (for object custom tags).
* All tag-to-asset mappings that the tag produced.

{% hint style="danger" %}
Deleting a custom tag cannot be undone. The tag and all of its historical associations will disappear from filters, group-bys, and Domains across Seemore.
{% endhint %}

***

## How Tags Are Applied

| Tag type             | When applied                                                               |
| -------------------- | -------------------------------------------------------------------------- |
| Snowflake (imported) | During each metadata sync (triggered by the integration scheduler)         |
| Query                | Continuously as new query history is processed; backfill available on save |
| Custom (queries)     | On save (7-day backfill) and on each subsequent query-history-analyzer run |
| Custom (objects)     | On save and during each integration-metadata-import run                    |

***

## Permissions Summary

| Action                              | Minimum role                          |
| ----------------------------------- | ------------------------------------- |
| View all tags                       | **Viewer**                            |
| Create / edit / delete Custom tags  | **Editor**                            |
| Trigger query or object association | **Editor**                            |
| Manage Query tags                   | Built-in — not configurable           |
| Manage Snowflake tags               | Managed in Snowflake — not applicable |