Skip to main content
Saved Dataset Pairs and Tests can become recurring controls for production loads and pipeline releases. General Validation hosts the definitions and run history; your customer execution environment performs each comparison and retains exact results and row evidence.

​
Choose a recurring scope

Use a stable source and target that should reconcile. For incremental loads, configure Pair filters so both sides cover the same completed window. Run the checks after both outputs are ready and avoid changing the compared data while the validation is in progress. If a migration source is being retired, create a replacement Pair with a reference that will remain available. A Pair’s source and target selections cannot be changed after creation. Retain or archive the migration Pair to keep its configuration and history. A passing migration Run records that migration scope; later Runs need their own meaningful source and target. For choosing checks, see When to validate, and what to check.

​
Run from the application

Owners and Contributors can use Run test for one saved Test, Run pair for the active Tests on a Pair, or Run all in Results for the configured scope offered by that action. Review readiness and entitlement messages before submission. Save any changes before running. Each Run preserves the submitted Test versions and configuration, so editing a Test later does not rewrite its historical rule.

​
Connect your existing orchestrator

The current hosted application does not include a built-in schedule editor. Use your own scheduler, deployment workflow, or pipeline orchestrator with the API and automation guide when validation must run at a specific time or after a successful load. A recurring workflow should:
  1. Wait for the source and target outputs to finish.
  2. Submit the intended validation scope with an authenticated application identity and the required idempotency key.
  3. Retain the accepted Run identity and poll according to the API response.
  4. Wait for execution and result delivery, then evaluate the final verdicts.
  5. Route execution errors and data discrepancies to the appropriate team.
Choose missed-run recovery and retry policy in your orchestrator. Reuse an idempotency key only for a retry of the same submission; a later scheduled validation is a new request. Follow the published API contract for request bodies, roles, and concurrency controls.

​
Use validation as a release gate

Before a pipeline or platform change reaches production, run representative Pairs against the completed new output. Review the selected scope, thresholds, missing rows, and any permitted discrepancies as part of the release decision. A successful ADF execution is only one stage: wait for delivered validation outcomes before treating the gate as complete. For runtime or Fabric changes, retain a representative baseline and rerun the same checks after the change. Include the fields and data shapes your users rely on; a check cannot establish correctness outside its compared scope.

​
Keep the history and evidence usable

Use Results to search and filter Run history and follow a Test across Runs. The hosted history contains configuration, verdicts, counts, diagnostics, and validated artifact references. Exact values and captured rows remain in your Azure Storage and are read directly by an authorized browser. Set Storage retention and reviewer access so evidence remains available for as long as your control requires. Removing an artifact can leave its metadata in Run history while making the exact result preview unavailable. See Runs, results & evidence and Security and data boundary.

​
Maintain capacity and readiness

An active Pair consumes subscription capacity. Archiving a Pair preserves its configuration and history and removes it from authoring and execution; it frees an active capacity slot. Trial lifetime creation limits still include archived and deleted Pairs. Check Billing for your current entitlement and Environment for runtime readiness. If source access or schemas change, refresh and prepare the affected Datasets before the next Run. See Subscription and activation for ongoing access.