Skip to main content
This guide takes you from a connected catalog to a first row-count comparison. You author the Test in the hosted application; validation runs in your Azure environment.

Before you start

  • Sign in to your General Validation Organization as an Owner or Contributor. Readers can review existing results.
  • Complete Getting started and check that your Environment is ready.
  • Have two supported outputs that should contain the same number of rows. Use a completed load or a stable reporting window so they represent the same data.
  • Have available Pair capacity and an active trial or subscription. Check Billing if authoring or execution is unavailable.

1. Connect a discovery source

Open Discovery. Choose an existing source, or have an Owner connect your Azure Data Factory or Microsoft Fabric workspace. Follow the source’s guided access checks, then open its catalog. An ADF source exposes dataset metadata. A Fabric source exposes Lakehouse and Warehouse tables through their SQL endpoints. Catalog discovery and customer schema preparation return metadata to the hosted service; source and target rows remain in your environment.

2. Import and prepare both datasets

Choose the source and target objects and select Import selected. For an individual catalog item, use Import & prepare. General Validation starts schema and access checks in your customer execution environment automatically after import. Open each imported item from Datasets. Wait for Ready for validation. The inventory shows Ready to pair when pairing is available. If an item shows Needs attention, follow its readiness explanation before proceeding. Catalog visibility alone does not mean its data can be validated. See Supported scope for the accepted connectors, formats, schemas, and field types.

3. Create a Dataset Pair

Open Pairs → + Dataset Pair, or choose Create Pair from the source Dataset. Name the Pair and select the source and target Datasets. Review the compatibility feedback and choose Create Pair. The source is the reference you want to reconcile against the target. Both sides can use different supported formats or catalogs. For example, the source can be an ADF Azure SQL Database table and the target a Fabric Lakehouse table. For this first row-count Test, join keys are unnecessary. If you need to compare a particular load or reporting window, configure structured source and target filters on the Pair so both sides cover that scope.

4. Create an exact row-count Test

On the Pair, select Create Test and set: Select Create Test. This checks whether the filtered source and target have exactly the same number of rows. It does not compare individual field values.

5. Run the saved Test

In the workspace explorer, open the Test’s ••• menu or right-click it and choose Run test. Run pair runs the active Tests on the Pair. Run actions use saved definitions; save any edits before running. Open Results and select the Run. You can follow its progress and select a Test to inspect its outcome. Customer ADF performs the comparison, writes the result in your Azure Storage, and delivers bounded status and verdict metadata to the hosted application. A passing row-count result confirms the counts reconciled for this scope. An error means the work needs operational attention; a failed validation means the completed comparison did not meet the rule. See Runs, results & evidence.

6. Add checks for the data that matters

Once the first Test runs, add the checks that define correctness for this Pair:
  • SUM or AVG for numeric totals and averages.
  • COUNT or COUNT_DISTINCT for populated and distinct field values.
  • MIN or MAX for extrema in supported field types.
  • VALUE for values on matched keys, or OUTER_VALUE to include rows missing from either side. Configure up to five Pair join-key columns first.
  • Set functions for containment or equality of field-value sets.
For numeric equality, Threshold is an absolute difference: 0 requires an exact match, while 5 allows a difference up to 5. Non-numeric comparisons require zero threshold. Set membership is exact; strict < and > ignore the threshold. The editor offers only compatible fields and supported comparison options. See Supported scope for type, transform, null, and duplicate-key rules. Value and set Tests have two separate settings:
  • Allowed failed rows controls how many comparison failures are permitted before the Test fails. Use 0 to require every compared row to pass.
  • Failed-row capture limit controls how many affected rows are retained in your Azure Storage. Use 0 to disable capture.
The capture limit does not change the verdict. An authorized browser reads exact values and captured rows directly from your Storage account when you open a result; application membership alone does not grant that Storage access.

If preparation or authoring is blocked

Open the Dataset and follow the stated remediation. Refresh metadata reads changed source metadata. Start preparation, Retry preparation, or Recheck Dataset appears when the corresponding check is available. Resolve source permissions, network access, incomplete schemas, or unsupported shapes in your environment. If the data has no supported execution route, materialize a supported flat dataset or choose a supported table. Use Troubleshooting and logs for help locating the failed operation.