Equal To Field Check FAQ

Answers to common questions about how the Equal To Field check compares two columns, how the comparators work, and how anomalies are reported, grouped by topic.

Behavior

Which two values does the check compare?

The evaluated field and the column named in Field to compare, read from the same row. The comparison never crosses rows or containers.

How are NULL values treated?

Without a comparator, NULLs pass: a row where either side is empty is not reported. Once any comparator is configured, only a row that is NULL on both sides passes, so a row filled in on one side and empty on the other is reported. Pair with Not Null when both columns must always be filled in.

Why is my tolerance not applied?

Check that you set the comparator for the type you are comparing: String for text, Datetime for dates and timestamps, Numeric for numbers. A comparator set for the wrong type is not silently ignored: the check is rejected with a 422 when you save it.

Can the String comparator ignore case?

No. Its only option is Ignore Whitespace, which trims both sides and collapses runs of internal whitespace. Text comparison is always case-sensitive, so EMEA and emea are reported as different.

What happens if the reference column itself is wrong?

The check passes: it proves the two columns agree, not that either is correct. Validate the reference column with its own check when it matters.

Can I compare a column in another table?

Not with this rule. Use Data Diff, which pairs rows between two containers and reports what differs.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: The field '<field_name>' has value <value>, which is not equal to the value of '<compared_field>'

Shape Anomaly: For the field '<field_name>', X.XXX% of N records (K) are not equal to the value of '<compared_field>'

When a filter is set, both messages end with [filter: <expression>].

Does Equal To Field produce Record Anomalies, Shape Anomalies, or both?

At 100% coverage (the default), violating rows are reported as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset. A scan can also roll up a large number of Record Anomalies into one Shape Anomaly.

Does Custom Anomaly Description work for Equal To Field?

Yes. Equal To Field emits Record Anomalies, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) replaces the Record Anomaly message with the value of the named column on the violating row. When that column is null, missing, or empty, the standard Record template is used instead. The Shape Anomaly always uses the fixed template.

Configuration

Can I lower the coverage on an Equal To Field check?

Yes. Coverage at 1.0 (100%) means every row must pass. Lowering coverage to 0.995 allows up to 0.5% of rows to fail without raising an anomaly; once the failing fraction goes past that, the check reports a Shape Anomaly. Use lower coverage with care: a real regression that happens to fall just under the threshold will not raise an alert at all.

Can I change the compared field later?

Yes. In the UI, open the check, pick a different Field to compare, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates the properties object. The rule type, the target container, and the associated Check Template stay immutable.

What permission do I need to create or edit an Equal To Field check?

The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.

Should I use Equal To Field or Equal To?

Use Equal To Field when the reference is another column, which keeps the rule correct as the data changes. Use Equal To when the reference is a fixed constant.