# How to use a Righthand with Airtable

Review an Airtable intake queue using base and table identities, record IDs, field mappings, and reconciled pagination.

By Righthand Team · 2026-10-09

Source: https://www.righthand.ai/blog/how-to-use-righthand-with-airtable

## Make one Airtable view a reliable intake queue

Use Righthand with Airtable to prepare a review queue from a named base and table. The output should retain each record ID and show the fields that determine its next step. A record's display name is convenient for people, but it is a weak key when two requests have the same title.

Airtable's [list-records documentation](https://airtable.com/developers/web/api/list-records.md) describes pagination and notes that empty fields can be omitted from returned records. That matters when interpreting checkboxes or missing values. The assistant needs a field mapping and completeness rules, rather than assuming every absent key means extraction failed.

## Specify the schema and access

Provide the base, table, approved view or filter, and field names. For an illustrative procurement intake, use Request ID, Requester, Item, Needed by, Approval status, and Purchase reference. These are example names; map them to the actual schema before reviewing records.

Check the tools available in [integrations](/integrations). A read route may expose records without every update operation. If needed, supply an approved CSV containing record identities and its snapshot time. The report should distinguish exported data from a live table read.

## A complete first-run brief

> At 9 AM America/Los_Angeles on Monday, review the approved procurement-intake view. Return a private queue grouped into missing information, approval review, and already linked purchases. Preserve Airtable record ID, requester, needed-by date, and exact approval value. Do not order items, change records, or assume approval from a checked box without the attached policy. Send to me for operations-lead review. Reconcile all retrieved pages and the final record count against the view, with excluded records listed separately.

The example is illustrative. A view filter may hide records that the reviewer expects to see. Include the filter definition so the owner can explain a count mismatch.

## Expected result and mapping decisions

An example item could read: “Record rec-example; item present; needed-by date absent; approval status Pending; ask requester for timing.” A separate item with a purchase reference should be checked against that reference before proposing another purchase.

For linked records, retain the linked identity and the supplied display value. Do not treat an unresolved linked ID as a blank relationship. If the export flattens multiple linked records into one cell, preserve the original value and flag ambiguous parsing.

## Reconcile before updates

Finish pagination before concluding the queue is complete. A maximum-record setting can truncate the result even when the first page looks normal. If access fails midway, state the coverage and return an incomplete review.

When the owner approves supported updates, target exact record IDs and only the approved fields. Retrieve the records again and compare the resulting values with the change worksheet. A renamed field or altered view requires a refreshed mapping, not a guessed replacement.

Set connection authority through [Righthand's permissions guide](https://docs.righthand.ai/guides/add-a-connection). Review [pricing](/pricing) for a recurring intake responsibility and keep its reviewer explicit.