Module 5: Airtable and Notion

Views, Filters, and Relationships

Capsule description

In capsule 05, the first question of the decision framework was: "do the data relate to each other?". If the answer was yes, you left Sheets. This capsule explains what that capability is — and the other two that truly set Airtable and Notion apart from a sheet: views and filters.

These three things — views, filters, relationships — are not "optional advanced features". They are the whole point of moving up the structure scale. A sheet with types would just be a stricter sheet; what makes Airtable and Notion different tools is that the data can relate, be seen in many ways without duplication, and be filtered persistently.

For an n8n workflow, relationships are the most important of the three — and also the most confusing. This capsule teaches you to work with them without getting tangled: the key, again, is the IDs.

What you'll learn

✅ Understand what relationships are between tables/databases
✅ Read and write relation fields from a workflow (with IDs)
✅ Resolve a relation: from the ID to the real data
✅ Understand views and why a workflow almost always ignores them
✅ Use filters from the workflow vs filters saved in the tool
✅ Decide when to model something as a relation and when not to

Relationships: the heart of the capsule

What a relationship is

A relationship connects a record in one table with one (or several) in another table. Examples:

An order is related to a customer (each order belongs to a customer)
A task is related to a project
A contact is related to a company

In Sheets, "relating" meant copying the customer's name into every order row, or using VLOOKUP. Fragile: if the customer changes their name, you have the old one in 40 orders. In Airtable (Link to another record field) and Notion (Relation property), the relationship is native and live: the order points to the real customer; if the customer changes, the order keeps pointing to that same updated customer.

The key for a workflow: relationships are handled with IDs

This is the most confusing and most important thing in the capsule:

A relation field does not store the name of the related record — it stores its ID (Record ID in Airtable, Page ID in Notion).

When you read a record with a relation, the relation field arrives as a list of IDs, not as names.

When you write a relation, you send it IDs, not names.

This ties directly to what you learned in Slack (capsule 05 of Module 4): serious systems work with stable IDs, not with names that change. Airtable and Notion are the same.

Writing a relation: the pattern

You want to create an order related to the customer "Acme Corp". You don't send "Acme Corp" to the relation field — you send Acme's Record ID. But your workflow probably only has Acme's name. The pattern:

1. Search the customer "Acme Corp" in the Customers table  (Search → gives you its Record ID)
2. Create the order, mapping the relation field to the found Record ID

It's "look up before acting" again (Module 1) — but here the lookup isn't to avoid duplicates, it's to resolve the name to an ID before you can link.

Reading a relation: resolving the ID to the data

The reverse: you read an order and its customer field comes as ["recABC123"] — an ID, not a name. If you need the customer's name:

1. Read the order  (its customer field = ["recABC123"])
2. Get the customer by that Record ID  (gives you the full record, with the name)

Always look at the real output. A relation field arrives as a list of IDs — confirm it by running the node and observing. Don't assume it arrives as text.

Views: why the workflow almost always ignores them

A view is a saved way of looking at the same data: a "pending only" view, a "grouped by assignee" view, a calendar view, a kanban one. The data is the same — the view only changes how it's presented, filtered, and sorted.

Views are great for the humans who use Airtable/Notion. But for an n8n workflow:

A workflow almost always wants the data, not a presentation of the data. The workflow reads the table/database and applies its own filter — it doesn't need the "pretty" view. Views exist for people; the workflow goes straight to the records.

There's a useful exception: some nodes let you read from a specific view, which gives you "the records that view already filtered". It can be convenient (you delegate the filter to the view). But it creates a dependency: if someone edits the view, your workflow changes behavior without you touching anything. That's why, in general:

Recommendation: have the workflow apply its own filter explicitly, instead of depending on a view. It's more predictable — the filter lives in the workflow, not in a setting someone else can change.

Filters: in the workflow vs saved in the tool

There are two places a filter can live:

Filter...	Lives in...	Trait
From the workflow	The n8n node (Filter By Formula in Airtable, Filters in Notion)	Explicit, versioned with the workflow, predictable
From a view	Airtable/Notion	Convenient, but someone can change it without warning

You already saw the workflow's filters in capsules 03 (Airtable: Filter By Formula) and 04 (Notion: Filters). The recommendation is the same as with views: the filter your workflow needs, put it in the workflow. That way the workflow's behavior doesn't depend on external settings that can change.

This is consistent with everything you've learned in the guide: the workflow must be predictable. A hidden dependency (a view, a saved filter someone edits) is exactly the opposite of predictable.

When to model something as a relation

Not everything has to be a relation. Criterion:

Model as a relation when...	Leave it as text/select when...
The related record has a life of its own (the customer exists independently of the order)	It's just a fixed label or category (an order's "status")
You need to navigate between them (see all of a customer's orders)	You never need to "go to the other side"
The related data changes and you want it to be reflected	The value is stable and simple

Over-relating is as real a mistake as under-relating. If a contact's "country" is never going to be a record with its own data, make it a select, not a relation to a "Countries" table. Relate what truly is an entity with a life of its own.

Common traps

Trap 1: Sending a name to a relation field

What happens: You send "Acme Corp" to the relation field. It fails, or links nothing — the field expects an ID.

How to avoid it: Look up the record first (Search → Record ID / Page ID), and send the ID to the relation field.

Trap 2: Expecting a read relation to bring the name

What happens: You read a record and its relation field is ["rec123"]. You expected "Acme Corp".

How to avoid it: Relations arrive as lists of IDs. If you need the real data, do an extra Get with that ID.

Trap 3: Depending on a view for the workflow's filtering

What happens: The workflow reads "from the Pending view". Someone edits that view and the workflow starts processing other records — without anyone touching the workflow.

How to avoid it: Put the filter in the workflow, explicit. Don't depend on external settings.

Trap 4: Over-relating

What happens: You turn into relations things that were simple labels (status, priority, country). Your base becomes a maze of tables.

How to avoid it: Relate only what is an entity with a life of its own. Everything else, select or text.

Trap 5: Forgetting that writing a relation implies a prior lookup

What happens: You design a workflow that "creates an order with its customer" in a single node, without accounting for needing to look up the customer first.

How to avoid it: Writing a relation is two steps: look up the related record (get its ID) and then create/update with that ID. Plan it that way.

Exercise: work with a relation

Goal: practice the full pattern of writing and reading a relation.

Setup

In Airtable (or Notion), create two related tables:

Companies: with a name field. Create 2-3 companies.
Contacts: with name, email, and a relation field company that points to Companies.

Your task

Write a relation: workflow that receives a contact with the name of its company → looks up that company in the Companies table (Search) → creates the contact in Contacts mapping the company field to the found Record ID
Verify in Airtable/Notion that the contact was actually linked to the company
Read a relation: workflow that reads a contact → observe that the company field comes as an ID → do a Get of the company with that ID to obtain its real name

See hints

In #1: the Search of Companies gives you the Record ID in its output. That ID is what goes into the Create's relation field — usually as a single-element list.
In #3: confirm by looking at the output that company is ["rec..."]. The Get with that ID returns the company's full record.
The lesson: a relation always implies a lookup step — to write it (name→ID) or to read it fully (ID→data).

Summary and next step

Views, filters, and relationships are the whole point of moving up the structure scale — not optional features
A relationship connects records of two tables/bases in a native and live way — unlike Sheets' fragile VLOOKUP
Key for workflows: relation fields are handled with IDs, not names — writing a relation implies looking up the record first; reading it fully implies a Get with the ID
Views are for humans — a workflow almost always wants the raw data and applies its own filter
Put the filter in the workflow, don't depend on views or saved filters someone can change — the workflow must be predictable
Model as a relation only what is an entity with a life of its own; everything else, select or text
5 traps: name to a relation field, expecting a name when reading, depending on views, over-relating, forgetting the prior lookup

Before moving on you should be able to:

Write and read a relation field using IDs
Explain why a workflow ignores views
Decide what to model as a relation and what not to

What comes next (capsule 07):

You already master the two tools and what makes them special. Capsule 07 covers what breaks in production: rate limits, structure changes, each API's problems, and handling the IDs when something doesn't add up. Airtable and Notion troubleshooting.

Additional resources

Airtable: link fields - How relationships work in Airtable.
Notion API: relations - How relation properties work in Notion.
Airtable / Notion: views - What views are and what they're for (to humans).

Created: May 14, 2026 Version: 1.0

← PreviousWhen to Use Each Next →Airtable and Notion Troubleshooting