Can I change a tag template field's type after tables are already tagged with it?

No, not directly, Data Catalog doesn't support in-place type changes on an existing field once tags reference it. Changing STRING to ENUM (or any type change) means adding a new field and migrating existing tag values across, the old field type is fixed for the life of that field ID.

What's the practical difference between an ENUM field and a STRING field for something like classification?

An ENUM field constrains input to a fixed, curated list (shown as a dropdown in the console and enforced on programmatic tag creation), while a STRING field accepts anything. For any metadata dimension you intend to filter, report, or build policy on later, ENUM is almost always the right choice, a STRING classification field will eventually accumulate 'Confidential', 'confidential', and 'CONFIDENTIAL' as three different values that a filter query treats as distinct.

Does isRequired get enforced retroactively on tables tagged before the field was marked required?

No, isRequired is enforced only at tag-creation or tag-update time going forward. Existing tags created before a field became required aren't automatically invalidated or flagged, so tightening a template's required fields doesn't retroactively fix already-incomplete tags, you'd need a separate audit pass to find and backfill them.

GCP Data Catalog Tag Template Builder

MonitoringGCP

Build Data Catalog tag template configurations with typed fields, enum values, and display ordering.

Tag Template Configuration

Template ID

Display Name

Field 1

Field ID

Display Name

Type

Required

Description

Template ID is required
Display name is required
Field 1: ID is required
Field 1: Display name is required

Generated Tag Template JSON

Output will appear here...

What This Tool Does

Build a Data Catalog tag template, a typed schema (STRING, DOUBLE, BOOL, ENUM, TIMESTAMP, RICHTEXT fields) that gets attached to BigQuery tables, Pub/Sub topics, and other catalog entries as structured, queryable business metadata, rather than free-text descriptions nobody can filter on. An ENUM field's allowedValues become a fixed dropdown in the console, catching typos like 'Confidental' that a free-text 'classification' field would happily accept and that would then quietly break any downstream policy or query filtering on exact string match.

Technical Details

The tool validates each field locally as you build it and only renders output once every field has a non-empty id, displayName, and type, and any ENUM field has at least one allowed value, mirroring the Data Catalog API's own rejection of a tag template with an incomplete field definition, before assembling the Tag Template resource with fields keyed by their field ID as the API expects.

Common Use Cases

1Defining a data_classification ENUM field with allowedValues PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED so every tagged table gets one of four fixed values instead of whatever free-text string someone typed that day.
2Marking a data_owner STRING field isRequired so a tag can't be attached to a table without naming an accountable owner, closing a common gap where sensitive tables get cataloged but nobody owns them.
3Adding a TIMESTAMP field for last_pii_review so a compliance dashboard can query catalog entries for tables overdue for their periodic sensitive-data review.
4Building a lighter-weight tag template for non-critical datasets (just owner and classification) versus a stricter one for regulated data, since applying the same heavyweight schema everywhere makes tagging low-stakes tables enough friction that teams skip it.

Common Questions

Can I change a tag template field's type after tables are already tagged with it?: No, not directly, Data Catalog doesn't support in-place type changes on an existing field once tags reference it. Changing STRING to ENUM (or any type change) means adding a new field and migrating existing tag values across, the old field type is fixed for the life of that field ID.
What's the practical difference between an ENUM field and a STRING field for something like classification?: An ENUM field constrains input to a fixed, curated list (shown as a dropdown in the console and enforced on programmatic tag creation), while a STRING field accepts anything. For any metadata dimension you intend to filter, report, or build policy on later, ENUM is almost always the right choice, a STRING classification field will eventually accumulate 'Confidential', 'confidential', and 'CONFIDENTIAL' as three different values that a filter query treats as distinct.
Does isRequired get enforced retroactively on tables tagged before the field was marked required?: No, isRequired is enforced only at tag-creation or tag-update time going forward. Existing tags created before a field became required aren't automatically invalidated or flagged, so tightening a template's required fields doesn't retroactively fix already-incomplete tags, you'd need a separate audit pass to find and backfill them.

Expert Tips

TIP

Field IDs are permanent once created and used in a live tag, plan the field ID naming (snake_case, unambiguous) carefully up front since renaming later means creating a new field and migrating data, not an in-place rename.

TIP

A tag template with more than a handful of required fields creates real friction for whoever is tagging tables manually, keep required fields to the two or three that genuinely block downstream governance decisions, and make the rest optional.

TIP

Tag templates are project-scoped by default; a template meant to be used consistently across a multi-project data platform needs an explicit sharing/IAM setup so other projects' catalog entries can actually reference it.

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?

Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.

GCP Data Catalog Tag Template Builder

MonitoringGCP

Build Data Catalog tag template configurations with typed fields, enum values, and display ordering.

Tag Template Configuration

Template ID

Display Name

Field 1

Field ID

Display Name

Type

Required

Description

Template ID is required
Display name is required
Field 1: ID is required
Field 1: Display name is required

Generated Tag Template JSON

Output will appear here...

What This Tool Does

Technical Details

Common Use Cases

1Defining a data_classification ENUM field with allowedValues PUBLIC, INTERNAL, CONFIDENTIAL, RESTRICTED so every tagged table gets one of four fixed values instead of whatever free-text string someone typed that day.
2Marking a data_owner STRING field isRequired so a tag can't be attached to a table without naming an accountable owner, closing a common gap where sensitive tables get cataloged but nobody owns them.
3Adding a TIMESTAMP field for last_pii_review so a compliance dashboard can query catalog entries for tables overdue for their periodic sensitive-data review.
4Building a lighter-weight tag template for non-critical datasets (just owner and classification) versus a stricter one for regulated data, since applying the same heavyweight schema everywhere makes tagging low-stakes tables enough friction that teams skip it.

Common Questions

Can I change a tag template field's type after tables are already tagged with it?: No, not directly, Data Catalog doesn't support in-place type changes on an existing field once tags reference it. Changing STRING to ENUM (or any type change) means adding a new field and migrating existing tag values across, the old field type is fixed for the life of that field ID.
What's the practical difference between an ENUM field and a STRING field for something like classification?: An ENUM field constrains input to a fixed, curated list (shown as a dropdown in the console and enforced on programmatic tag creation), while a STRING field accepts anything. For any metadata dimension you intend to filter, report, or build policy on later, ENUM is almost always the right choice, a STRING classification field will eventually accumulate 'Confidential', 'confidential', and 'CONFIDENTIAL' as three different values that a filter query treats as distinct.
Does isRequired get enforced retroactively on tables tagged before the field was marked required?: No, isRequired is enforced only at tag-creation or tag-update time going forward. Existing tags created before a field became required aren't automatically invalidated or flagged, so tightening a template's required fields doesn't retroactively fix already-incomplete tags, you'd need a separate audit pass to find and backfill them.

Expert Tips

TIP

Related Learning Guides

Firestore Data Modeling26 min read
Cost Optimization Guide24 min read

Was this tool helpful?