After Date Time Best Practices

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

Pick the cutoff with the strict comparison in mind

The comparison is strict greater-than (>): a row whose value equals the cutoff is flagged. When the boundary itself should be allowed, set the cutoff earlier than the first value you want to accept. Getting this wrong on a busy table produces a burst of false anomalies at exactly the boundary instant.

How much earlier depends on where you set it. The form's date and time picker goes down to the minute, so the closest you can get there is the preceding minute, and values inside that minute pass as well. Through the API you can send an exact instant, down to fractions of a second, which closes that window when the extra minute matters. On a Date field, one day earlier is the natural step.

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. After Date Time asserts that present values fall after 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 After 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 pre-cutoff rows is expected (for example, during a slow migration), 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 After Date Time when the question is "is every value after a specific moment in time" (a go-live, a migration, a fiscal-year start).
Use Freshness when the question is "is the data recent enough": its boundary moves with the clock, while After Date Time's cutoff is fixed.
Pair with Before Date Time to build a time window with independently managed bounds, or use Between when the window is fixed.
Pair with Not Future to require that timestamps fall after a historical cutoff AND not in the future.

Route the anomalies to the right people

Set an Anomaly Assignee so boundary violations land with the team that owns the pipeline, and tag the check (migration, ingestion) 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.