Airtable Linked Records in Automations

The Field That Behaves Differently

Linked records are the reason to use Airtable over a spreadsheet. A lead connects to its calls, a project to its tasks, an invoice to its line items, natively rather than through a formula matching text across tabs.

They also behave unlike every other field type in automations, and almost everyone hits the same two problems in their first week.

Problem One: It Gives You an ID, Not a Name

Read a linked record field expecting "Acme Ltd" and you get something like recA1b2C3d4E5f6G7.

That's the linked record's ID. It's correct, and it's useless in an email template. Sending it to a customer produces a message with a database identifier where the company name should be.

Two ways to fix it.

A lookup field. Add a lookup on the source table that pulls the name from the linked record. Your automation reads the lookup field, which contains readable text. Simplest, works everywhere, and it's what we use by default.

A second fetch. Read the ID, then make another request to fetch that record and take its name. More requests, more to go wrong, and it counts against your rate limit, which matters at volume for the reasons in Airtable rate limits and 429 errors.

Use the lookup field unless you need more than one value from the linked record.

One wrinkle: lookups return arrays, because a record can link to several. Even with exactly one link, you often get ["Acme Ltd"] rather than "Acme Ltd". Most connectors have a way to take the first item, and forgetting to produces emails addressed to ["Acme Ltd"].

Problem Two: Writing Replaces Instead of Appending

The one that causes actual damage.

Write to a linked record field and, in most tools, you replace whatever was there. A job linked to three previous invoices, plus your automation adding a fourth, ends up linked to only the fourth. The other three links are gone, silently, and nothing errors.

To append rather than replace: read the current value first, add your new ID to that list, and write the whole list back. Three steps instead of one, and it's the difference between adding a link and destroying history.

Worth testing deliberately on a throwaway record before running anything against real data, because the damage isn't obvious until someone asks where the earlier records went.

Creating a Link to Something That Might Not Exist

The common flow: an order arrives with a customer name, and you want the order record linked to the customer record.

Search the customer table by your key field. If found, use its ID. If not found, create the customer, capture the new ID, then use it. Then write the ID into the order's linked field.

The failure here is searching by name. Names aren't unique or stable, so you get either the wrong link or a duplicate customer. Match on a normalised email, a phone, or a stored external ID. Same key-field discipline as syncing Airtable to your CRM without duplicates.

Some connectors offer to create a linked record automatically when you write a name that doesn't exist. Convenient, and it creates a new record on any spelling variation, so you end up with "Acme Ltd", "Acme Limited" and "acme ltd" as three customers. Turn it off and handle the search-or-create explicitly.

Filtering a View on Linked Records

Views can filter on linked record fields, and the behaviour catches people.

Filtering on the linked field itself compares against record IDs, which is rarely what you want in a readable filter. Filtering on a lookup of the linked record's name works the way you'd expect and reads properly to a human.

This matters if you're using views as your automation's logic, which is the pattern we recommend in Airtable views as automation logic. A filter that reads "Customer status is active" via a lookup is self-documenting. One comparing raw IDs is not.

Performance at Volume

Linked records are cheap to read and less cheap to traverse.

A workflow reading a record, following its links, then following those records' links, makes a request per hop. Do that per record across a few hundred and you'll meet the rate limit.

The fix is fetching the related table once at the start of the run and matching in memory rather than requesting per record. One call instead of hundreds.

The Habits Worth Having

Add a lookup field for anything an automation needs to read as text, and name it clearly so the next person knows why it exists.

Read before writing to any linked field, always, unless you genuinely intend to replace.

Match on stable keys rather than names when creating links.

Test link-writing on a throwaway record before pointing it at real data.

Airtable automation: what it can and can't do covers where the native layer fits, and connecting Airtable to Google Sheets and Gmail covers the wider integration patterns.

Book a free 60-minute call and we'll check whether anything you're running is quietly overwriting links, and rebuild the ones that are.