Detect data anomalies in your Airtable bases

Airtable bases decay quietly: empty required fields, the same client entered twice, a date in the wrong year. An Orkeste agent reads a table on the schedule you set, lists what looks wrong and proposes fixes. An ops lead approves each fix before the record is updated.

The problem

Errors are found when a report looks wrong or a client receives the wrong email. By then, they have spread to everything built on the table.

How the workflow runs

Runs: Every day or every week.

  1. Read the records: The agent reads the records of the table named in its briefing.
  2. Check the rules: It checks required fields, formats, value ranges and likely duplicates against your rules.
  3. Report: It posts the list of problems to Slack.
  4. Propose fixes: Where the right value is clear, it prepares the update.
  5. Approve: Each fix waits in Validations for the ops lead.
  6. Update: Approved fixes are written to the records.

Every fix waits in Validations; nothing changes in the table without approval.

Who does what

What this workflow does not do

Works with your stack

Questions about this workflow

Can it remove duplicates?

It finds likely duplicates and lists them, but it does not delete or merge records. A person removes them in Airtable.

How do I define what counts as an anomaly?

In plain language in the briefing: required fields, allowed values, date ranges, how to recognise the same client twice.

Can it check Google Sheets?

Not today. Agents see spreadsheets by name but do not read cell values. Use Airtable for data that agents check.

Related workflows

Keep reading