Skip to main content

Tagging and Classification

Learn how to tag and classify your data assets in Coalesce Catalog so you can discover, govern, and secure your data effectively.

Why Tag and Classify Data?​

Tags improve how you find and manage data assets. Here's what they do:

  1. Improve discoverability: You can filter and search by tags instead of relying on asset names or schemas alone.
  2. Support governance, compliance, and security: Tags help you apply retention rules, access policies, and compliance controls (for example, PII or sensitive data).
  3. Provide semantic context: Tags describe content, usage, ownership, quality, and business relevance in a way that both technical and non-technical audiences can understand.

Tagging in Catalog: Coalesce Catalog lets you import existing tags from your sources and add new tags directly in Catalog.

Imported vs Catalog-Managed Tags

We recommend keeping imported tags focused on technical and lifecycle metadata (for example, source, platform, stage). Use Catalog-managed tags for governance, compliance, and discovery tags that non-technical audiences need. This keeps technical metadata in sync with your sources while allowing you to layer business semantics in Catalog.

Tag Origins and Terminology​

Catalog uses three tag origins. These map to the concepts above:

OriginMeaning
User tagsCatalog-managed tags created by your team in Catalog
External tagsImported from your sources (warehouses, BI tools)
Catalog tagsAuto-added by Catalog when it parses queries or detects sources (for example, source detection)

Only User tags can be edited. See Tag Manager for admin workflows.

Add Tags to Your Assets​

To add tags to assets, you can import them from your sources or create them in Catalog. See Add tags to assets for step-by-step instructions.

Faceted Tag Format​

We recommend using faceted tags that specify type:meaning. This format makes tags easier to search, filter, and govern.

Examples:

  • domain:finance, domain:marketing
  • function:compliance, function:risk
  • concept:customer, concept:invoice
  • useCase:ML, useCase:reporting
  • sensitivity:PII, sensitivity:confidential
  • quality:incomplete, quality:trusted
  • stage:UAT, stage:production
  • source:CRM, source:GoogleAds
  • expirydate:20270101

Types of Tags​

To be effective, tags should be meaningful, consistent, and governed. The categories below are a starting point, not an exhaustive list.

Business Context Tags​

Business context tags add business meaning to data assets.

Examples:

  • Domain: Finance, Marketing, HR
  • Sub-domain or function: Compliance, Inbound, Talent
  • Business entity (concept): Customer, Invoice, Product
  • Use case (optional): Reporting, Forecasting, ML Feature Store

Benefits: Helps you find data by business relevance rather than technical schemas.

Sensitivity and Compliance Tags​

These tags classify data by sensitivity, privacy, or legal requirements.

Examples:

  • PII, PHI, Confidential, Public
  • GDPR, HIPAA, Crown Jewels

Purpose:

  • Drives access control policies
  • Enables audit readiness
  • Lets you mark sensitive assets without exposing their contents

Quality and Trust Tags​

These tags are optional. You can replace them with data quality tests and certification or deprecation workflows, or use them alongside. They capture data quality and reliability.

Examples:

  • High Quality, Stale, Incomplete
  • Trusted, Reviewed, Deprecated

Purpose:

  • Guides you before consuming data
  • Integrates with governance and stewardship workflows in Catalog

Technical Metadata and Lifecycle Tags​

These tags are very often imported from your source systems. They provide technical context and lifecycle state.

Examples:

  • Data source type: Snowflake, Redshift, Postgres
  • Lifecycle maturity: Development, Staging, Production, ExpiryDate
  • Type: KPI, Microservices
  • Source: CRM, GoogleAds. Source tags are one example of the source: facet that Catalog adds automatically.

Purpose:

  • Enables filtering and grouping in user interfaces
  • Aligns with data lifecycle policies

Knowledge Structure​

Not every tag needs a corresponding entry in the Knowledge section. We recommend adding a knowledge page for each tag you add so you can explain what that tag means and how to use it.

Here's an example of how you might structure knowledge around your tags:

Business Domain (key domains)

  • Finance (list of functions)
    • Compliance
    • Risk
  • HR
    • Talent
    • Recruitment

Business Entity (typically conceptual, optional)

  • Customer
  • Product

Metrics (list of metrics with tags linking to the relevant domain and function)

  • Revenue (groupings by metric type)
    • ARR
    • NRR
    • GRR

Glossary terms (groupings, acronyms, and business jargon)

  • Territory
    • EMEA
    • Central
  • QBR
  • GDPR

Sources (data sources)

  • Google Ads
  • Salesforce
  • HubSpot

New Assets​

Catalog highlights assets added in the last 30 days so contributors know what to document and review. For warehouse tables, tables are not flagged as new if their schema was created in the last 7 days.

What's Next?​