Skip to main content
Saved Table Pairs and their Tests can become recurring controls for production loads and pipeline releases. General Validation keeps the definitions and Run history; the exact values and row evidence stay in your Fabric tenant.

​
Choose a recurring scope

Use a stable source and target that should reconcile. A Table Pair’s source and target Tables cannot be changed after creation; Edit Table Pair changes only its name, join keys, and filters. If a source is being retired, create a replacement Table Pair and keep or archive the old one for its history. For incremental loads, set source and target filters so both sides cover the same completed load window or partition; filters apply to every Test in the pair. There is no atomic snapshot across the two Tables, so run after both outputs are ready and avoid changing the compared data while a Run is in progress. For choosing Tests, see When to validate.

​
Rerun after each load

  1. Open the Table Pair and click Run validation, or choose it from the row’s ⋯ menu on Table Pairs. To rerun every Table Pair that has Tests, click Run all in the workspace header.
  2. Open Results to review Runs newest first. Each Run link can be bookmarked, and Refresh Result on a Run imports its latest summary.
Each Run freezes the Table Pair, its Tests, and their settings, so later edits never change a recorded Result. Treat a failed Test as a data finding: the comparison disagreed beyond its threshold or bad-record allowance, and View details shows the exact values or a sample of mismatched rows. Treat an error as something to fix in access or configuration before the next Run: Could not read the Tables means the job could not read a source or target Table, usually because the person who ran it lacks read access, and The Test could not finish means a mapped column is missing or unusable with that function.

​
Scheduling and notifications

This release has no built-in scheduler and sends no notifications. Every Run starts from the app when an Owner or Contributor clicks Run validation or Run all, and the Run page or Results is where you learn the outcome. The API can author Table Pairs and Tests and prepare Runs, but cannot submit a Run to Fabric or read exact values; see API and automation.

​
Use validation as a release gate

Before a pipeline or platform change reaches production, run the representative Table Pairs against the completed new output and review the verdicts, mismatch counts, and any permitted differences as part of the release decision. For runtime or Fabric changes, keep a passing baseline Run and rerun the same Tests afterwards; a Test proves nothing outside its compared scope.

​
Keep the history and evidence usable

Run history stays in Results, including Runs of archived Table Pairs. Exact values and mismatched rows stay in your Results Lakehouse; you own those files and control their retention, and removing the Environment deletes them. For Run status, details, and retention, see Runs, Results, and evidence and Security and the data boundary.

​
Work as a team

  • Readers review Results and open details once a Fabric workspace administrator has shared the dedicated workspace with them; Organization membership alone does not grant that access. Only an Owner or Contributor can start a Run, and a Result is recorded in General Validation only when one of them refreshes it.
  • Edit Tests deliberately. Edit Test and Edit Table Pair apply to future Runs and reset the current badge to Not run until the new definition has a Result; past Runs keep their frozen configuration.
  • Delete Table Pair archives the pair: it leaves active views, frees a plan slot, and takes no new Tests or Runs, while its history stays in Results.
  • Every active Table Pair counts toward your plan limit, and Billing shows how many are in use. Archive a pair or ask an Owner to change the plan before adding more; see Plans and trial.