§ Stack · Airtable

Record validation inside Airtable.

Airtable is the system of record for a growing chunk of mid-market back offices — ops teams use it as a lightweight database, vendor tracker, intake queue, content pipeline, and project manager. What Airtable doesn’t give you out of the box is scheduled rule-based validation. Airtable’s built-in field validation catches things at write time, but drift accumulates silently afterward: fields that were required become optional, rules change, integrations write garbage values. A scheduled validator reads the tables, runs rules, and produces a “needs review” view.

Works on any paid Airtable plan

Validation reads via the standard Airtable API. Free tier API call limits make regular validation impractical at meaningful volume (the process burns through the daily API allocation just scanning mid-sized bases). Team tier and above is the practical floor.

Scheduled sequence

1. Scheduled run — nightly is typical; hourly for high-volume tables; weekly for reference tables that change rarely.
2. For each configured table, the process queries all records (or the records modified since the last run, for large tables).
3. Each record is scored against the configured rules: required fields populated, enum fields within allowed values, relational integrity (linked records exist and are not archived), date ranges valid, cross-field consistency (close date after open date, end date after start date), format conformance (email fields match pattern, phone fields match format).
4. Failing records are collected into a “needs review” output. Depending on configuration, this is either a dedicated Airtable view (records tagged with a validation_status field), an email summary to the admin, or a Slack digest to a dedicated channel.
5. The admin reviews each flagged record in the Airtable UI, fixes what needs fixing, and the next scheduled run confirms the fix.

Rules are explicit, not learned

Every validation rule is defined in a config the admin owns. Rules are added, edited, removed with an explicit change. The process does not silently learn new rules from past rejections, does not auto-tune thresholds, does not adjust severity on its own. If the admin wants to relax a rule, they edit the config and commit the change. This matters because the most common failure mode of any validation system is silent drift — a rule loosens over time because “it was producing too many false positives” and nobody notices until the database is full of records that should have been caught.

What it does not do

• Does not edit records in Airtable. Flagging is the whole product. Silent auto-edits corrupt production data and are almost never safe.
• Does not override admin-entered values, even if a rule would “prefer” a different value.
• Does not notify record owners directly. The single review surface is the admin’s queue. That’s deliberate — routing validation failures to record owners creates pressure to mark records “valid” to get them off the list, which defeats the purpose.
• Does not run heuristic ML. Rules are SQL-style predicates. If you can’t express the rule as “this field equals / contains / matches / is between,” the validator is the wrong tool.

Typical month after go-live

The first two weeks are ugly. A base that has drifted for a year will produce thousands of validation failures on the first scheduled run — most of which are real. Admin works through the backlog in 1–2 hour daily sessions. By week three the queue stabilizes to 10–40 new failures per day, most of which are genuine intake issues that need a human decision. The value of the system is not in zero failures — it’s in catching failures the same day they happen, instead of six months later when they’ve propagated to downstream reports.

See also: data-quality analyst role, Drive intake.