Skip to main content
A Run records execution progress and the outcome of its validation Tests. The hosted application stores the submitted configuration, status, verdicts, counts, diagnostics, and evidence references. Exact result values, deltas, and captured rows remain in your Azure environment.

​
The run lifecycle

Before submission is accepted, General Validation checks permissions, entitlement, environment readiness, and whether the requested scope can run. A rejected submission does not create a Run. Once accepted, work progresses through these stages:
  1. Validate the saved Test definitions, source access, schemas, and runtime requirements.
  2. Execute the comparison through your customer-owned Azure Data Factory.
  3. Write authoritative results and optional failed-row evidence in your Azure Storage.
  4. Deliver bounded result metadata and confirm that the received results match the submitted work.
ADF success is followed by result delivery. Wait for the final reported outcome before deciding that a validation passed. A completed comparison can fail its rule even though execution succeeded; an execution or delivery error requires operational attention.

​
Find a Run and select a Test

Open Results. Search by Run name, function, or Run ID, and narrow the history with Status and Scope filters. Click a column heading to sort; filtering and sorting apply across the history, including later pages. Open a Run and select a Test in its navigator. The selected item shows its progress, accepted verdict when available, captured rule, and relevant diagnostics. The Error filter includes execution failures and result errors. Use Load more to retrieve additional attempts and results. Each Run preserves the submitted Test versions and configuration. Historical results continue to show the rule used at submission even if you later edit the Test.

​
Read the outcome and exact values

The outcome summary uses the accepted verdict and reliable counts. A Test can pass with discrepancies if its Allowed failed rows setting permits them. The sampled rows are evidence for investigation; their number is not a substitute for the reported total. When you open a delivered result, the browser automatically loads its available exact metrics and failed-row previews directly from the registered customer Storage account. Comparison cards show source, target, and difference values where the function produces them. Captured rows are grouped into mismatches and rows missing from either side. This direct read uses your signed-in identity’s delegated Storage access. Being a Reader, Contributor, or Owner in General Validation does not by itself grant access to the underlying Storage data. Vendor APIs do not proxy the preview. See Security and data boundary. A denied or unavailable preview does not change an already accepted verdict. Use its inline Retry control after resolving consent, Storage permissions, network access, or artifact availability.

​
Preserve result types

Different functions produce different observations. An absent source value, target value, delta, threshold, or aggregate is not zero or an empty string. A delta can be absent when safe subtraction cannot be established; use the verdict rather than treating the absent delta as an execution failure. Numeric thresholds use decimal JSON strings in the API. Exact result values are customer-side data: the hosted Result resource leaves exact-value and delta fields null and publishes validated artifact references for a separate authorized read. Automation must use the delivered verdict and count fields, not interpret those null exact-value fields as a missing comparison. The browser preserves numeric precision and distinguishes text, null, and binary values. For response fields and nullability, see the Result schemas in the API reference.

​
Failed-row evidence and retention

Value and set Tests can retain a bounded number of affected rows. Failed-row capture limit controls that bound, and 0 disables capture. It is independent of Allowed failed rows, which controls the verdict. Aggregate Tests produce summary observations rather than failed-row evidence. Your Azure Storage holds the authoritative results and browser artifacts. Retain them under your organization’s policy and grant access to the reviewers who need them. If an artifact is deleted or inaccessible, the hosted Run record can still show its metadata while the exact preview is unavailable. For a review or cutover, record the Run ID, scope, outcomes, and customer artifact references in your own approval system. The current hosted application provides per-Run result review; generated HTML evidence packs and in-app sign-off are not available in this workflow.

​
Cancel, retry, and recover

Owners and Contributors can request cancellation of active work. Cancellation is a request to stop execution; use the resulting Run state to determine what finished. A confirmed transient ADF infrastructure failure receives one automatic retry after 60 seconds. Other errors need their stated remediation. For a terminal Run, Retry incomplete items first recovers failed result delivery on the same Run when validation already succeeded, avoiding another validation execution. After delivery recovery, eligible remaining validation failures can be retried. A conflicting immutable completion receipt is not eligible for delivery retry. Temporary status-read failures retain the last visible Run state and show a reconnecting indicator. If automatic checks pause, Retry status check resumes reading status; it does not submit another validation. For error-specific next steps, see Troubleshooting and logs.