Skip to main content
Run validation when you need evidence that two outputs reconcile. General Validation’s hosted application manages the Table Pairs, Tests, and Run history; each comparison executes in the dedicated General Validation workspace on your own Fabric capacity, in your own tenant. Choose a source and target Table covering the same completed load or time window. The Tests establish whether that scope meets the configured rules. They do not establish correctness for untested columns, untested rows, or business logic upstream of the reference source. Tests compare outcomes; they do not reproduce your transformation. For function semantics, see The 12 validation functions. For authoring, see Create Table Pairs.

​
When you build or change a pipeline

After a mapping, join, transformation, or sink change, and before you promote it, compare the completed new output against the reference output. Start with COUNT_ROWS, then add SUM and COUNT_DISTINCT on columns affected by the change. Use VALUE on stable join keys to compare individual columns, and OUTER_VALUE when rows missing from either side must be included. Apply Table Pair filters if the Tests cover a deliberate subset. A passing Result supports the release decision for those configured Tests. Widen coverage when a change can affect more Tables or columns than the initial scope.

​
When pipelines run in production

Reconcile each completed load after both source and target outputs are ready. General Validation reads the source and target separately; there is no atomic snapshot across the two, so start a Run only after both sides are complete. When one side must stay fixed, pin a Delta version on that Lakehouse Table (Source Delta version or Target Delta version in the Table Pair). Warehouse Tables cannot be pinned. Use COUNT_ROWS and meaningful aggregates as recurring Tests, then add keyed value comparisons for the columns where a discrepancy matters. To scope Tests to one load window, filter the Table Pair on the column that identifies the load, such as a load date or batch identifier. Open the pair, click Edit Table Pair, add the matching filter with Add source filter and Add target filter, and click Save Table Pair. Filters apply to every Test in the Table Pair, and summaries and evidence use the same filtered inputs. After you change filters, the pair’s Tests show Not run until the new definition has a Result. The filter fields are described in Create Table Pairs. Set the evidence capture limit (Evidence limit on the Test) on VALUE, OUTER_VALUE, and set Tests when investigators need examples of mismatched or missing rows. The evidence stays in the Results Lakehouse in your OneLake; your browser reads it directly with your own Microsoft identity, and it is never sent to General Validation. See Runs, Results, and evidence. A person starts each Run from the app; General Validation does not schedule Runs. Run validation on a Table Pair submits one Run. Run all in the workspace header submits a Run for every Table Pair that has Tests, one after another, then opens Results and reports how many Runs reached Fabric and any Table Pair that was rejected. Table Pairs without Tests are skipped, and Readers do not see Run all. See Validate on an ongoing basis.

​
When the platform changes

Before a Fabric change such as a capacity move or a Spark runtime upgrade, or a change to how a Lakehouse or Warehouse is loaded, retain a representative reference output and a baseline of Tests. Run the same Tests against the completed output after the change. Include counts, aggregates, keyed values, and the column types your workloads rely on. Review the selected scope and any tolerated differences: the Absolute threshold on every Test except set Tests, and Max bad records on row and set Tests. Coverage is limited to the Table Pairs and Tests in the baseline.

​
When you migrate or cut over

Pair the Table written by the old pipeline with the Table written by the migrated pipeline. Any combination of Lakehouse and Warehouse Tables can form a Table Pair; outputs that are not Fabric Tables must be loaded into one first, as described in Supported data. Start with row counts and aggregate reconciliation, then add VALUE and OUTER_VALUE on keyed Table Pairs for the columns that must match. Review the delivered Results and the retained evidence before making a cutover decision. Record the Run ID, scope, and Results in your organization’s approval process. A Run freezes the Table Pair, its Tests, and their settings when it is prepared, so later edits do not change what a past Run compared, and Run links can be bookmarked or reloaded. Deleting a Table Pair after cutover archives it; its Runs and Results remain in Results. The full workflow is in Validate a migration to Fabric.