Module 5: Airtable and Notion

Airtable: Records and Tables

Capsule description

Airtable is the easiest tool in this module to adopt, because it looks like a spreadsheet — rows, columns, a grid. But that familiarity hides the difference that matters: in Airtable, each column has a type, and the tool stops you from entering data that doesn't respect that type.

That changes everything for a workflow. In Sheets (Module 1) you had to be disciplined by hand — remember to format the phone as text, watch that dates didn't break. In Airtable, the structure protects you: if a column is "date", garbage doesn't fit; if it's "select", only the valid options fit. The workflow can trust the shape of the data.

This capsule covers Airtable's vocabulary (bases, tables, records, fields), the core operations (read, create, update records) and — the core — how to work with field types from a workflow.

What you'll learn

By the end of this capsule you'll be able to:

✅ Understand Airtable's vocabulary: base, table, record, field
✅ Read and search records with filters
✅ Create and update records from a workflow
✅ Work with field types and why they matter
✅ Use the Record ID to point to a specific record
✅ Apply "search before you act" in Airtable

Airtable's vocabulary

Term	What it is	Equivalent in Sheets to...
Base	A container of related tables	A Sheets document
Table	A collection of records of the same type	A tab/sheet
Record	A row — an individual record	A row
Field	A column with a defined type	A column (but with no type)
Record ID	The unique identifier of each record	(Sheets didn't have this)

The two differences that matter compared to Sheets: the fields have a type, and each record has its own ID — you don't depend on "row 7", you have a stable identifier (as you learned in Calendar with the Event ID).

The core operations

The Airtable node, with Resource: Record, offers:

Operation	What it does
Search / List	Read records (with or without a filter)
Get	Bring a record by its ID
Create	Create a new record
Update	Modify an existing record
Upsert (Create or Update)	Create or update based on a key column
Delete	Delete a record

If you did Module 1, this sounds familiar: they're the same Google Sheets operations. The logic is identical — what changes is that here the data has structure.

Read and search records

Read with a filter

Operation: Search
Base and Table: yours
Filter By Formula: the search condition

Airtable filters with formulas — its own mini-language. Examples:

{status} = "pending"
{city} = "CDMX"
AND({status} = "pending", {city} = "CDMX")

Field names go between braces {}. It's more expressive than the Sheets filter (you can combine conditions, compare, etc.), but it has its syntax — check Airtable's formula reference when you need something more complex.

As always: filter, don't bring everything. And as with Sheets, the filter value can be dynamic — build the formula with n8n expressions to search for the data that came in through the trigger.

What each record gives you

A record you read arrives with:

Its id (rec...) — the Record ID
Its fields — an object with each column and its value

Look at the real output before building. The field types affect how each value arrives: a "multiple select" field arrives as a list, a "link to another table" field arrives as a list of Record IDs, not as text. Don't guess — look at them.

Create and update records

Create

Operation: Create
Map each field to its value, just like Module 1's mapping

The difference from Sheets: Airtable validates what you write. If a field is of type "number" and you send it text, or if a "single select" field receives an option that doesn't exist, Airtable rejects the record. That's good — the error appears immediately, not weeks later with corrupted data — but it means your mapping has to respect the types.

Update

Operation: Update
Record ID: {{ $json.id }} — the record to modify
Map only the fields that change

As in Sheets and Calendar: Update is surgical, it only touches what you map. And it needs the Record ID to know which one it points to — get it from a previous Create, a Search, or wherever you saved it.

Upsert

Operation: Upsert (Create or Update)
You define a key column to match on

Just like Sheets' "Update or Append": if it finds a record with that key it updates it, if not, it creates it. The star operation for syncing.

Work with field types

This is the part that sets Airtable apart. The most common types and how to handle them from a workflow:

Field type	How to send it a value
Single line text / Long text	Normal text
Number	A number (not text) — convert with `{{ Number($json.x) }}` if needed
Date	A date in a format Airtable accepts (ISO 8601 is the safe one)
Single select	One of the options that already exist in the field
Multiple select	A list of existing options
Checkbox	`true` or `false`
Link to another record	A list of Record IDs from the other table (not text)

The rule: an Airtable mapping that works is one that respects the types. Before mapping a field, be clear about what type it is. The two most confusing: single/multiple select (the value must be an option that already exists — Airtable doesn't create it on its own by default) and link to another record (you don't send it a name, you send it the Record ID of the linked record — more on relationships in capsule 06).

The "search before you act" pattern in Airtable

The same pattern from Module 1, with an advantage: here each record has a stable ID.

Trigger
   │
   ▼
Airtable (Search, Filter By Formula: {email} = "...")
   │
   ▼
IF: did the search return 0 records?
   │
   ┌──────────┴──────────┐
   ▼ YES (doesn't exist) ▼ NO (already exists)
 Airtable (Create)       Airtable (Update, Record ID from the search)

Or, simpler for many cases: Upsert with the key column, which does the same in one node. Just like in Sheets: use the explicit pattern when "exists / doesn't exist" triggers different logic; use Upsert when only the content changes.

Common traps

Trap 1: Sending a Single Select an option that doesn't exist

What happens: Your workflow tries to set status = "in review" but that field only has the options pending, approved, rejected. Airtable rejects the record.

How to avoid it: For select fields, the values must be options that already exist. Create the options in Airtable first, or make sure your workflow only sends valid values.

Trap 2: Treating a Link field like text

What happens: You want to link a record to another and you send the name ("Client Acme"). The field is "Link to another record" and expects a Record ID, not a name.

How to avoid it: Link fields receive Record IDs from the linked table. You have to search the target record first, get its id, and send it. (Capsule 06 goes deeper into relationships.)

Trap 3: Sending numbers as text

What happens: A field is "Number" and you send it "100" (text). Depending on the case, Airtable rejects it or stores it strangely.

How to avoid it: Convert explicitly: {{ Number($json.amount) }}. Just like you learned in Sheets (Module 1, capsule 07), but here Airtable is stricter.

Trap 4: Pointing by position instead of Record ID

What happens: You try to update "the first record" or "the record in row 3". Airtable doesn't work by position.

How to avoid it: Airtable works with Record IDs. To update, get the record's id (from a Search) and use it.

Trap 5: Not looking at how each field type arrives

What happens: You read a record and {{ $json.fields.categories }} isn't the text you expected — it's a list, because the field is "multiple select".

How to avoid it: Run the Search, look at the real output, and observe how each field arrives based on its type.

Exercise: the full cycle in Airtable

Goal: practice reading, creating, updating while respecting the types.

Preparation

In your base Test CRM, table Contacts, create fields with varied types: name (text), email (text), priority (single select: high/medium/low), active (checkbox), signup_date (date).

Your task

Read with a filter: Manual Trigger → Airtable (Search, Filter By Formula {priority} = "high"). How many does it bring?
Create respecting types: Manual Trigger → Set → Airtable (Create) — a new contact where priority is a valid option, active is true, signup_date in ISO
Update: use the id of the created record to do an Update that changes priority to another valid option
Upsert: an Airtable (Upsert) with email as the key column — run it twice with the same email and check that it doesn't duplicate

See hints

In #2, priority must be exactly high, medium or low (the options you created); active = true (boolean, not text); signup_date = {{ $now.toFormat('yyyy-LL-dd') }}
In #3, the Record ID comes from the Create's output: {{ $json.id }}
In #4, notice that the second run updates the existing record instead of creating a new one

Summary and next step

Airtable looks like a sheet but each field has a type — and the tool stops you from entering data that doesn't respect it
Vocabulary: base (document) → table (tab) → record (row) → field (column with type); each record has a stable Record ID
Core operations identical to Sheets: Search, Get, Create, Update, Upsert, Delete
Airtable validates what you write — good (early errors), but your mapping must respect the types
The most confusing types: select (value must be an existing option) and link (receives Record IDs, not names)
"Search before you act" applies the same — with the advantage of the stable Record ID
5 traps: nonexistent select option, link as text, numbers as text, pointing by position, not looking at how each type arrives

Before moving on you should be able to:

Read, create, and update records while respecting the field types
Use the Record ID to point to a record
Explain why Airtable rejects certain values (and why that's good)

What comes next (capsule 04):

You know Airtable. Capsule 04 does the same with Notion: databases, pages, and properties. You'll see that Notion shares the idea of "structure" with Airtable, but wraps it in something different — its records are pages that can have rich content.

Additional resources

n8n Airtable node Docs - All the node's operations.
Airtable: filter formulas - The Filter By Formula syntax.
Airtable: field types - Reference of all field types.

Created: May 14, 2026 Version: 1.0

← PreviousConnect Airtable and Notion to n8n Next →Notion: Pages and Databases