Exists In Check FAQ

Answers to common questions about how the Exists In check looks values up against another container, how NULLs and the two filters behave, and how anomalies are reported, grouped by topic.

Behavior

Does the check enforce the relationship, or only report it?

It reports. The platform does not block writes; it flags the rows whose value has no match so the owning team can fix them.

Can the reference live in another datastore?

Yes. Set the reference Datastore on the Right Reference panel. Leave it empty when the reference container is in the same datastore as the target.

What is the difference between the two filter clauses?

The one on the main form scopes the target rows, deciding what gets evaluated. The one on the Right Reference panel scopes the reference rows, deciding which values are valid.

How are NULL values treated?

A NULL in the target field passes: there is no value to look up. Pair the check with Not Null when the value must also exist.

Can the target and the reference be the same container?

Yes. Point the reference at the same container and pick the field that forms the valid set. That is a common way to assert an internal relationship.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: <field> has the value <value>, which is missing from <reference field>

Shape Anomaly: <field> values are missing from <reference field>, affecting N of M asserted records

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Does Exists In 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.

Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly, which carries the Shape Anomaly message. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.

Does Custom Anomaly Description work for Exists In?

Yes. Exists In emits Record Anomalies, so the anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) applies.

When the option points at another column on the same row, the Record Anomaly message becomes that column's value for the violating row, shown as written. When the column is null, missing, or empty, the message falls back to the rule's standard wording, and when the column is masked the message reads <masked>. Shape Anomaly messages are unaffected.

Configuration

Can I lower the coverage on an Exists In 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 reference on an existing check?

Yes. In the UI, open the check, change the Right Reference panel, 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 Exists In 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.

How is Exists In different from Not Exists In?

They are mirror images. Exists In requires the value to exists the reference set; Not Exists In requires it to be absent from it.