Skip to content

Is Type Troubleshooting

Common problems when creating and running an Is Type 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.

Sentinel Values Like N/A Are Flagged

Rows holding N/A, -, or unknown are reported.

Cause: Those are present values that cannot be read as a number, a boolean, or a date, so they fail.

Resolution: Normalize them to NULL upstream (or with a Computed Field) when they mean "no value", or fix them at the source when they should carry real data.

Whole Numbers Are Flagged Against Fractional, or Decimals Against Integral

Numbers that look fine are reported.

Cause: Integral accepts whole numbers only, so 12.5 fails it; Fractional accepts both whole and decimal numbers.

Resolution: Pick the type the downstream consumer expects. Use Fractional when decimals are legitimate, Integral when they are not.

Dates in an Unusual Format Are Flagged

A column of dates fails an Is Type check for Date.

Cause: The value must be readable as a calendar date. Formats that are ambiguous or non-standard cannot be recognized.

Resolution: Normalize the column to an unambiguous form upstream (ISO-8601 is the safest), or use Matches Pattern when the rule is really about the shape of the text.

Empty Strings Are Flagged but NULLs Are Not

Rows with '' are reported while rows with no value pass.

Cause: An empty string is a present value that cannot be read as any testable type; NULL is absence and passes by design.

Resolution: This is expected. Pair with Not Null when absence should also be reported, and normalize '' to NULL upstream when the two should behave the same.

An Array Row Fails Although Most Elements Are Valid

A row with an array field is flagged even though only one element is wrong.

Cause: On array fields the check evaluates every element, and the row fails as soon as one element cannot be read as the expected type.

Resolution: This is expected behavior. Review the flagged row's array to find the offending element.

An Edited Check Keeps Behaving the Old Way

You changed the configuration 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 them. See What Happens to Existing Anomalies.

No Anomalies Although the Data Looks Wrong

A Scan ran, the data clearly breaks the rule, but nothing was reported.

Cause: One of these 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 and test the filter expression against the offending rows. Then 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.