Before Date Time Best Practices

Guidelines for getting reliable signal from Before Date Time checks while keeping the noise (and the maintenance) low.

Pick the cutoff with the strict comparison in mind

The comparison is strict less-than (<): a row whose value equals the cutoff is flagged. When the boundary itself should be allowed, set the cutoff one second (for timestamps) or one day (for dates) later than the last value you want to accept. Getting this wrong on a busy table produces a burst of false anomalies at exactly the boundary instant.

Enter the cutoff as an unambiguous instant

The cutoff is stored as a UTC instant, and the anomaly messages echo it as an ISO-8601 string with a Z suffix. When your source data carries values in mixed or local time zones, normalize the field upstream with a Computed Field before running the check, so the boundary means the same thing for every row. A cutoff that is off by a time zone offset silently passes (or flags) every row within that window.

Pair with Not Null when presence is required

NULL values pass the check. Before Date Time asserts that present values fall before the cutoff; it does not enforce that the field is populated. When the field must also be present, add a Not Null check on the same field. Relying on Before Date Time alone lets fully empty columns sail through.

Keep coverage at 100% unless a known backlog exists

At 100% coverage every failing row is reported as a Record Anomaly, which tells you exactly which rows crossed the boundary. Below 100% the check reports a single Shape Anomaly only when the failing fraction crosses the tolerance, and no per-row detail is produced. Lower coverage only when a small, known fraction of post-cutoff rows is expected (for example, while an archive is still being drained), and revisit the setting once the backlog clears.

Scope with a filter instead of loosening coverage

When only part of the table is subject to the boundary (one tenant, one partition, only active rows), express that with a filter clause rather than by lowering coverage. The filter removes the out-of-scope rows from evaluation entirely and keeps the check strict on the rows that matter; the filter expression is echoed in every anomaly message, so the evaluated scope stays visible.

Prefer a native Date or Timestamp column

The field picker only accepts Date and Timestamp fields, and comparisons on a natively typed column are cheaper and safer than re-interpreting a non-typed value at scan time. If the upstream column is a string, project it through a Computed Field with a Timestamp type before checking it. The check itself is one of the cheaper rule types to run: the cost scales linearly with the number of rows that pass the filter.

Choose the right rule for the job

Use Before Date Time when the question is "is every value before a specific moment in time" (an archive cutoff, a period close, a plausibility ceiling).
Use Freshness when the question is about how recent the newest row is, rather than about a ceiling every row must respect.
Pair with After Date Time to build a time window with independently managed bounds, or use Between when the window is fixed.
Use Not Future instead when the ceiling is "now" rather than a fixed instant: its boundary moves with the clock.

Route the anomalies to the right people

Set an Anomaly Assignee so boundary violations land with the team that owns the data, and tag the check (archive, period-close) so it is easy to find later. A dated cutoff usually belongs to a project with an end date; record the context in the check's description and additional metadata so future readers know when the check can be retired.