Skip to content

Expected Values Troubleshooting

Common problems when creating and running an Expected Values check, their causes, and how to resolve them.

Validation Fails When Creating the Check

Clicking Validate returns an error instead of a success message.

Cause: The rule could not run against the selected data. The most common reasons are an invalid Filter Clause expression, a connection problem with the source, or a container that failed to load.

Resolution:

  1. Review the error message: it explains what needs attention.
  2. Check the Filter Clause for typos: it must be a valid SQL WHERE expression for the selected container.
  3. If the message says the container is marked as Unloadable, the container was skipped after repeated operation failures. Follow the steps in Unloadable Container Error.

Every Non-NULL Row Is Flagged

The check reports essentially the whole column.

Cause: The list's type does not match the field's type. A list of strings on a numeric column (or the reverse) cannot be compared, so every value fails.

Resolution: Align the list with the column: numeric entries for numeric fields, true/false for boolean fields, strings for everything else. See Type Coercion and Matching Rules.

Values That Look Correct Are Flagged

A value in the anomaly message looks identical to an entry in the list.

Cause: Matching is case-sensitive and whitespace-sensitive. "o", "O", and " O " are three different values, and a trailing space is invisible in most viewers.

Resolution: Compare the flagged value character by character against the list. Fix the list entry, normalize the data upstream (or with a Computed Field), or switch to a Satisfies Expression check with lower(field) IN (...) when case should be ignored.

Date or Timestamp Values Never Match

A date column fails against a list of dates that look right.

Cause: There is no native date list. Values are compared as strings against the column's rendered form, so the list has to match that rendering exactly.

Resolution: Use the ISO-8601 form the engine produces (YYYY-MM-DD for Date, YYYY-MM-DD HH:MM:SS for Timestamp). For a range rather than a set, use Between Times instead.

Rows With NULL Values Are Not Flagged

Rows with an empty field pass the check.

Cause: This is by design: NULL values pass. Expected Values only constrains present values.

Resolution: Pair the check with a Not Null check on the same field to also require presence.

An Array Row Fails Although Most Elements Are Valid

A row with an array field is flagged even though only one element is out of vocabulary.

Cause: On array fields the check evaluates every element. A single element outside the list fails the whole row.

Resolution: This is expected behavior. Review the flagged row's array to find the offending element. Note that empty arrays and NULL arrays pass, since there is nothing to evaluate.

An Edited Check Keeps Behaving the Old Way

You added a value to the list but the anomaly list did not change.

Cause: Edits take effect on the next Scan. Saving the check does not re-evaluate the data, and anomalies raised under the previous configuration are not modified.

Resolution: Run a Scan on the container (or wait for the scheduled one). Old anomalies stay open until you triage them or a Full scan with Auto Resolve clears the ones the updated list now accepts. See What Happens to Existing Anomalies.

No Anomalies Although Values Are Out of Vocabulary

A Scan ran, the column clearly holds unexpected values, but nothing was reported.

Cause: One of three configurations is excluding the violations:

  • The check is in Draft status: Draft checks are not evaluated by Scans.
  • The Filter Clause excludes those rows before the evaluation runs.
  • Coverage is below 100% and the failing fraction stayed within the tolerance, so the check passed.

Resolution: Confirm the check is Active, test the filter expression against the offending rows, and review the coverage setting. See Coverage and Tolerance.

Expected One Anomaly per Row, Got a Single Rolled-Up One

Many rows failed, but the scan reported one Shape Anomaly instead of per-row Record Anomalies.

Cause: When the number of failing rows exceeds the scan's rollup threshold, the per-row findings are grouped into one rolled-up Shape Anomaly.

Resolution: This is expected behavior; the rolled-up anomaly carries sampled source records. To change the threshold, see Maximum Record Anomalies per Check.