Skip to main content
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Did you hear? There's a new SQL AI Developer certification (DP-800). Start preparing now and be one of the first to get certified. Register now

yexu
Microsoft Employee
‎03-19-2026 10:00 AM

Audit columns in Copy job in Fabric Data Factory—every row is traceable for data lineage and compliance

If you haven’t already, check out Arun Ulag’s hero blog “FabCon and SQLCon 2026: Unifying databases and Fabric on a single, complete platform” for a complete look at all of our FabCon and SQLCon announcements across both Fabric and our database offerings.

Introduction

Copy job is the go-to solution in Microsoft Fabric Data Factory for simplified data movement across multiple clouds. With native support for bulk copy, incremental copy, and change data capture (CDC) replication, it can handle a wide range of movement scenarios through an intuitive, easy-to-use experience.

When data lands in your analytics destination, one of the first questions a data engineer, analyst, or compliance officer will ask is: "Where did this row come from, and when did it get here?"

It's a simple question. But in most data platforms, answering it requires custom engineering. This metadata is essential for debugging data quality issues, meeting regulatory audit requirements, and building trust in your data platform.

Audit columns are now available in Copy job—a built-in capability that you can choose to automatically add data movement metadata to every row in your destination, giving you row-level visibility into when data was moved and where it came from, with zero code overhead.

What are Audit Columns?

Audit columns are additional metadata columns that Copy job can automatically append to every row it writes to the destination. These columns don't come from your source data—they're generated by the platform to describe the data movement itself.

When you enable audit columns in Copy job, each row in your destination table can be enriched with information such as:

Audit Column What It Captures
Data extraction time The timestamp when the row was extracted from the source by a Copy job run
File path The source file path the row was read from (applicable for file-based sources)
Workspace ID The Fabric workspace ID where the Copy job resides
Copy job ID The unique identifier of the Copy job item
Copy job run ID The unique identifier of the specific Copy job execution
Copy job name The name of the Copy job that moved the row
Lower bound The lower bound value of the incremental window for the current run
Upper bound The upper bound value of the incremental window for the current run
Custom A user-defined static value— add any additional context your team needs. For example, you can add your source server name here
Table 1: Audit Column list

With audit columns enabled, you can answer the following questions for any row in your destination table:

  • When was this data extracted? —Exact timestamp from when the row was read from the source.
  • Where did it come from? —Which file path, which data store.
  • Which job moved it? —Which Copy job from which Workspace, which specific run, by name and ID.
  • What is the incremental scope? —Lower and upper bounds tell you exactly what slice of data this run covers.
No custom code. No expression authoring. Add as many audit columns as you want, and every row in every table your Copy job writes will include this metadata automatically.

Supported connectors: Audit columns are supported on all Copy job connectors except Snowflake, Office 365, and Databricks Delta Lake.

Why Audit Columns Matter

Row-Level Data Lineage Without the Plumbing

Data lineage—knowing where data came from and how it got to its current state—is a foundational requirement for any serious data platform. But traditional approaches to lineage tracking typically operate at the job level: you know that Job X ran at 3:00 PM and wrote to Table Y. What you don't know is which specific rows were affected, when each row was written, or whether a particular row came from this run or a previous one.

Audit columns close this gap by embedding lineage metadata directly into the data. Every row carries its own provenance. This is row-level lineage—and it's fundamentally more useful than job-level metadata for debugging, auditing, and data quality.

Compliance and Regulatory Reporting

For organizations in regulated industries—financial services, healthcare, insurance, and government, the ability to trace data back to its source is not optional. Auditors need to answer questions like:

  • "When was this customer record last updated in our analytics system?"
  • "Can you prove this financial transaction data was sourced from the production ERP system?"
  • "Which data movement job brought this patient record into the data warehouse, and when?"
Without audit columns, answering these questions requires correlating external monitoring logs with destination table contents—a manual, error-prone, and time-consuming process. With audit columns, the answers are in the data itself. A simple SELECT query on the destination table tells you everything you need.

Data Quality and Debugging

When data quality issues appear—duplicate rows, stale data, or missing records—the first question is always: when did this row arrive, and where did it come from? Audit columns answer that instantly.

Without audit columns, you'd need to cross-reference workspace monitoring logs, match timestamps against row counts, and hope the correlation holds. With audit columns, the metadata is right there in the row.

Downstream Analytics and Freshness Tracking

Audit columns enable a class of downstream analytics that would otherwise require custom engineering:

  • Source file traceability—Use File Path to trace any row back to its exact source file.
  • Ingestion SLA monitoring—Compare Data Extraction Time against expected schedules to detect ingestion delays.
  • Incremental window auditing—Use Lower Bound and Upper Bound to verify that every incremental slice was processed, and nothing was missed.

Quick Guide: Steps

Enabling audit columns in a Copy job is straightforward and only takes a few steps.

Step 1: Create or Open a Copy job

In your Fabric workspace, start by creating a new Copy job or opening an existing one. Choose your source tables as you normally would.

Step 2: Add Audit Columns

In the Copy job setup, after selecting the source tables or folders to be copied, add audit columns. This automatically adds metadata columns to every destination table in your job.

Configure_audit_columnsConfigure_audit_columns

Figure 1: Configure Audit Columns

Step 3: Run your Copy job

Run the Copy job. With each execution, every row written to the destination table will include audit column values such as extraction time, workspace ID, copy job name, run ID, and any custom metadata you’ve defined.

Step 4: Query your Data and Build Reports

Open your destination table and query the audit columns along with your business data for a complete context. Audit columns are standard table fields, so they work seamlessly with Power BI, KQL queries, and other tools. You can easily build dashboards for data freshness, monitor ingestion SLAs, and create compliance lineage reports without relying on external metadata stores.

Show_Audit_ColumnsShow_Audit_Columns

Figure 2: Show Audit Columns

Learn More

Submit feedback on Fabric Ideas and join the conversation in the Fabric Community.

If you have any questions or would like to provide feedback, please feel free to leave a comment.

0