Skip to content

Less Than Field Troubleshooting

Common problems when creating and running a Less Than Field 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.

Rows Where Both Values Are Equal Are Flagged

Rows where the two fields hold the same value are reported.

Cause: Inclusive is off, so the comparison is strict and equal values fail.

Resolution: Turn Inclusive on when an equal pair is legitimate, such as a single-day term or usage exactly at the quota.

Rows Where One Side Is NULL Are Not Flagged

Rows with a missing value on either column pass the check.

Cause: This is by design when no comparator is configured: with nothing to compare, the row passes, and a column that is entirely NULL therefore never fails this rule. With a Numeric or Datetime comparator configured the opposite happens, and a row with exactly one NULL is flagged: only a row where both values are NULL passes.

Resolution: Pair the check with Not Null on both fields when their presence is part of the rule.

Every Row Fails

The check reports essentially the whole table.

Cause: The relationship genuinely does not hold in that direction, most often because the target field and the compared field are the wrong way around, or because Inclusive is off on a column pair that is legitimately equal on most rows.

Resolution: Confirm which field belongs on the left of the comparison, and review the Inclusive setting. A pair of columns with different types cannot cause this, because the platform rejects such a check when it is saved.

Rows That Differ by a Rounding Difference Are Flagged

The check reports rows that are off by a fraction or by a few seconds.

Cause: With no comparator configured, the comparison is exact.

Resolution: Set the Numeric comparator for amounts or the Datetime comparator for timestamps, with a margin that matches the noise your pipeline introduces.

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.