Data Catalog Field Definition & Onboarding Form

Interactive onboarding form and template for cataloging datasets, capturing table- and field-level definitions, ownership, sensitivity, lineage, update cadence, SLAs, common transforms, data quality expectations, and an onboarding checklist.

Interactive Tool

Data Catalog Field Definition & Onboarding Form

Use this form to create a complete catalog entry and onboarding record for a dataset or table. Capture field-level definitions in a standard format, record owners and stewards, classify sensitivity and access, supply example queries and transforms, and confirm readiness for production. The form stores a structured submission that can be reused, audited, and iterated.

Field-level definitions are best provided as CSV, pipe-delimited rows, or JSON. A recommended row format is: column_name | data_type | nullable (Y/N) | description | example | common_transform(s). Example: customer_id | integer | N | Unique customer identifier | 32421 | hashed_for_analytics

A concise human-friendly name used in the catalog. Include environment or domain if helpful (e.g., Sales.orders_v2).
What is this dataset for? Who uses it? Explain main business purpose and typical analytic uses.
Exact technical identifier (database.schema.table, S3 path, topic name, etc.).
Provide one row per field using: column_name | data_type | nullable (Y/N) | description | example | common_transform(s). You may paste CSV, pipe-delimited lines, or JSON array of objects.
Person accountable for meaning, access decisions, and resolving business questions. Include email or team alias.
Person responsible for technical health, schema changes, and operational issues.
Classify the data according to organizational policy. If regulated, note the regulation (e.g., PII, PHI, PCI).
How do users request access? Which approvals or training are required? Include IAM roles, groups, or ticket process.
How often is this dataset updated? Choose the option that best fits the operational behavior.
How quickly should the dataset be restored or refreshed after an incident? Enter minutes for consistent tracking.
Document typical transformations applied upstream (e.g., joins, aggregations, normalizations, pseudonymization). Provide SQL or pseudocode where helpful.
List data quality problems, edge cases, incomplete fields, or limitations consumers should know.
List source systems, pipelines, and key transformation stages. If available, paste a short lineage snippet or reference a lineage diagram.
Who uses this data? List dashboards, reports, APIs, ML models, or teams that rely on it.
Include 1–3 example SQL queries or steps that show how to use the dataset for common tasks.
Comma-separated tags to improve discoverability (e.g., sales, billing, customer).
Reference IDs or names of closely related datasets that should be considered when reusing data.
Suggest the quality measures to monitor (e.g., row completeness %, unique key validity, freshness lag). Include thresholds if known.
Check items completed during onboarding.
Has the dataset met the criteria for production use? If 'No', explain in Known Issues or follow-up tasks.
Who is filling in this form? Useful for follow-up questions.
Use ISO date format for consistent records.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.

Discussion

Comments and conversation will live here.