How to generate Column Annotations with Copilot in Fabric: step by step

João Barros 11 de November de 2026 6 min read

This tutorial shows how to use Copilot in Fabric to generate automatic column annotations in a Lakehouse table. Documenting columns with descriptions and types is useful for discovery, governance and for teams to understand the meaning of the data. Consistent annotations help reduce onboarding time for new users (e.g. 30–50% less time to understand a dataset) and simplify integration with tools like Power BI and ETL processes.

Prerequisites

Account with access to Microsoft Fabric and permissions to edit a Lakehouse (at least the Owner or Data Curator role).
Data table loaded in the Lakehouse (for example a CSV imported as a table). Typical examples: a "Sales" table with columns order_id, price, currency, customer_email, order_date.
Copilot enabled in your Fabric instance and with permissions to access the Lakehouse context.
Basic SQL knowledge (SELECT, ALTER) and metadata concepts (semantic types, column comments).
Suggestion: show Copilot a sample of 100–1000 records for better examples and pattern detection.

Step 1: Identify the table and the purpose of the annotations

Choose the table in the Lakehouse whose documentation you want to improve. Decide the level of detail: short description (1–2 sentences), semantic_type (e.g.: currency, email, iso-country), example value, and validation rules (regex or simple checks). For example, for 10 critical columns (e.g. order_id, price, customer_email) you may request detailed descriptions; for 50 less critical columns, short descriptions may suffice. Also note the target audience: analysts, engineers or business users — this conditions the language used in the descriptions.

Step 2: Open Copilot in the table context

Navigate to the Lakehouse file list, select the table and open the Copilot pane (Copilot icon in the top-right corner of the Lakehouse UI). Opening Copilot in the table context allows it to reference columns and samples automatically — the model can read the first N records and infer formats. If you cannot open it in context, manually copy a schema or sample into the prompt.

Step 3: Create a prompt focused on annotations

Write a clear prompt that requests descriptions, semantic_type and examples for each column. Prefer a structured format (JSON) to facilitate later application. Explain the desired length of descriptions and the inventory of acceptable semantic_type (e.g. currency, email, iso-country, datetime, id, postcode, phone, person-name). Also include that rule_suggestion should be generated as regex or simple SQL checks.

{
  "prompt": "Analyze the columns of the 'Sales' table and generate metadata in JSON. For each column, return: name, description (1-2 sentences), semantic_type (ex: currency, email, iso-country), example_value and rule_suggestion (regex or SQL validation). Use samples from the first 100 records if needed.",
  "output_format": "json"
}

Examples of rule_suggestion: email -> "^[^@\s]+@[^@\s]+\.[^@\s]+$"; price -> "^\\d+(\\.\\d{2})?$" (value with two decimal places). These rules help automate quality checks.

Step 4: Run Copilot and review the result

Submit the prompt and wait for Copilot's response (usually seconds to 1–2 minutes, depending on sample size). The output should be a JSON with one entry per column. Review each field: descriptions should be concise and correct; semantic_type useful for discovery; example_value representative (not empty values) and rule_suggestion concrete and testable. If you find an incorrect semantic_type, note it to correct in the next prompt.

Example of a generated snippet (conceptual):

{
  "columns": [
    {"name": "price", "description": "Unit sale price in euros.", "semantic_type": "currency", "example_value": "19.99", "rule_suggestion": "^\\d+(\\.\\d{1,2})?$"},
    {"name": "customer_email", "description": "Customer email used for contact.", "semantic_type": "email", "example_value": "cliente@example.com", "rule_suggestion": "^[^@\\s]+@[^@\\s]+\\.[^@\\s]+$"}
  ]
}

Step 5: Adjust and iterate the prompt in case of common errors

Common errors: descriptions that are too vague, semantic_type that are generic (e.g.: string) or irrelevant examples. Refine the prompt by requesting more detail or limiting the scope to specific columns. For example, if Copilot did not correctly detect date formats, explicitly ask for "date format ISO 8601 or DD/MM/YYYY". Iterate until acceptable quality is achieved — typically 2–3 iterations for sets of 10–20 columns.

{
  "prompt": "Focus on the columns 'price', 'currency', 'customer_email'. For each, return: name, description (2 sentences), semantic_type (currency/email), example_value (from the dataset) and rule_suggestion. If there are no examples, return null."
}

Step 6: Convert the generated JSON into table changes

After validating the JSON, apply the annotations using the Fabric API (if available) or via the Lakehouse UI. A simple approach is to generate a SQL script that updates column comments. If you have 20 columns, generate 20 ALTER commands automatically from the JSON.

-- Conceptual example: apply description via SQL
ALTER TABLE Sales ALTER COLUMN price SET COMMENT 'Unit price in euros, excluding VAT';
-- For multiple columns, generate dynamically based on the Copilot JSON

If you prefer to validate the rule_suggestion before applying, run SQL checks such as:

SELECT COUNT(*) AS invalid_emails FROM Sales WHERE NOT (customer_email REGEXP '^[^@\s]+@[^@\s]+\.[^@\s]+$');

Verify the result

Confirm that descriptions appear in the Lakehouse catalog and that tools like Power BI or Data Insights surface the annotations. Also test the validation suggestions by running the checks (e.g. count records that fail the regex). Record before/after metrics (e.g. number of invalid records) to measure impact. If you implement this in an ETL pipeline, add these validations as automated steps and log alerts when the error percentage exceeds a threshold (e.g. 1%).

Conclusion

Using Copilot in Fabric to generate column annotations saves time and brings consistency to data documentation; the next step is to automate this flow (e.g.: schedule monthly reviews) and integrate the rule_suggestion into ETL pipelines. Practical tip: start with a critical subset of 5–10 columns, validate results and then scale to the full catalog. Always keep a human review cycle to ensure semantic quality — would you like to try generating annotations for a critical subset first?