Módulo 5: Airtable y Notion

Vistas, Filtros y Relaciones

Descripción de la cápsula

En la cápsula 05, la primera pregunta del marco de decisión era: "¿los datos se relacionan entre sí?". Si la respuesta era sí, salías de Sheets. Esta cápsula explica qué es esa capacidad — y las otras dos que de verdad separan a Airtable y Notion de una hoja: vistas y filtros.

Estas tres cosas — vistas, filtros, relaciones — no son "funciones avanzadas opcionales". Son la razón de ser de subir en la escala de estructura. Una hoja con tipos sería solo una hoja más estricta; lo que hace a Airtable y Notion herramientas distintas es que los datos pueden relacionarse, verse de muchas formas sin duplicarse, y filtrarse de forma persistente.

Para un workflow de n8n, las relaciones son lo más importante de los tres — y también lo que más confunde. Esta cápsula te enseña a trabajar con ellas sin enredarte: la clave, otra vez, son los IDs.

Lo que vas a aprender

✅ Entender qué son las relaciones entre tablas/bases de datos
✅ Leer y escribir campos de relación desde un workflow (con IDs)
✅ Resolver una relación: del ID al dato real
✅ Entender las vistas y por qué un workflow casi siempre las ignora
✅ Usar filtros desde el workflow vs filtros guardados en la herramienta
✅ Decidir cuándo modelar algo como relación y cuándo no

Relaciones: el corazón de la cápsula

Qué es una relación

Una relación conecta un registro de una tabla con uno (o varios) de otra tabla. Ejemplos:

Un pedido está relacionado con un cliente (cada pedido pertenece a un cliente)
Una tarea está relacionada con un proyecto
Un contacto está relacionado con una empresa

En Sheets, "relacionar" significaba copiar el nombre del cliente en cada fila de pedido, o usar BUSCARV. Frágil: si el cliente cambia de nombre, tienes el viejo en 40 pedidos. En Airtable (campo Link to another record) y Notion (propiedad Relation), la relación es nativa y viva: el pedido apunta al cliente real; si el cliente cambia, el pedido sigue apuntando al mismo cliente actualizado.

La clave para un workflow: las relaciones se manejan con IDs

Esto es lo que más confunde y lo más importante de la cápsula:

Un campo de relación no guarda el nombre del registro relacionado — guarda su ID (Record ID en Airtable, Page ID en Notion).

Cuando lees un registro con una relación, el campo de relación llega como una lista de IDs, no como nombres.

Cuando escribes una relación, le mandas IDs, no nombres.

Esto enlaza directo con lo que aprendiste en Slack (cápsula 05 del Módulo 4): los sistemas serios trabajan con IDs estables, no con nombres que cambian. Airtable y Notion son iguales.

Escribir una relación: el patrón

Quieres crear un pedido relacionado con el cliente "Acme Corp". No le mandas "Acme Corp" al campo de relación — le mandas el Record ID de Acme. Pero tu workflow probablemente solo tiene el nombre de Acme. El patrón:

1. Buscar el cliente "Acme Corp" en la tabla Clientes  (Search → te da su Record ID)
2. Crear el pedido, mapeando el campo de relación al Record ID encontrado

Es "buscar antes de actuar" otra vez (Módulo 1) — pero aquí el lookup no es para evitar duplicados, es para resolver el nombre a un ID antes de poder enlazar.

Leer una relación: resolver el ID al dato

Al revés: lees un pedido y su campo cliente viene como ["recABC123"] — un ID, no un nombre. Si necesitas el nombre del cliente:

1. Leer el pedido  (su campo cliente = ["recABC123"])
2. Get del cliente por ese Record ID  (te da el registro completo, con el nombre)

Mira siempre el output real. Un campo de relación llega como una lista de IDs — confírmalo ejecutando el nodo y observando. No asumas que llega como texto.

Vistas: por qué el workflow casi siempre las ignora

Una vista es una forma guardada de mirar los mismos datos: una vista "solo pendientes", una vista "agrupada por responsable", una vista de calendario, una de kanban. Los datos son los mismos — la vista solo cambia cómo se presentan, filtran y ordenan.

Las vistas son geniales para los humanos que usan Airtable/Notion. Pero para un workflow de n8n:

Un workflow casi siempre quiere los datos, no una presentación de los datos. El workflow lee la tabla/base de datos y aplica su propio filtro — no necesita la vista "bonita". Las vistas existen para las personas; el workflow va directo a los registros.

Hay una excepción útil: algunos nodos permiten leer desde una vista específica, lo que te da "los registros que esa vista ya filtró". Puede ser cómodo (delegas el filtro a la vista). Pero crea una dependencia: si alguien edita la vista, tu workflow cambia de comportamiento sin que toques nada. Por eso, en general:

Recomendación: que el workflow aplique su propio filtro explícitamente, en lugar de depender de una vista. Es más predecible — el filtro vive en el workflow, no en una configuración que alguien más puede cambiar.

Filtros: en el workflow vs guardados en la herramienta

Hay dos lugares donde puede vivir un filtro:

Filtro...	Vive en...	Característica
Del workflow	El nodo de n8n (Filter By Formula en Airtable, Filters en Notion)	Explícito, versionado con el workflow, predecible
De una vista	Airtable/Notion	Cómodo, pero alguien puede cambiarlo sin avisar

Ya viste los filtros del workflow en las cápsulas 03 (Airtable: Filter By Formula) y 04 (Notion: Filters). La recomendación es la misma que con las vistas: el filtro que tu workflow necesita, ponlo en el workflow. Así el comportamiento del workflow no depende de configuraciones externas que pueden cambiar.

Esto es coherente con todo lo que has aprendido en la guía: el workflow debe ser predecible. Una dependencia oculta (una vista, un filtro guardado que alguien edita) es justo lo contrario de predecible.

Cuándo modelar algo como relación

No todo tiene que ser una relación. Criterio:

Modela como relación cuando...	Déjalo como texto/select cuando...
El registro relacionado tiene vida propia (el cliente existe independientemente del pedido)	Es solo una etiqueta o categoría fija (el "estado" de un pedido)
Necesitas navegar entre ellos (ver todos los pedidos de un cliente)	Nunca necesitas "ir al otro lado"
El dato relacionado cambia y quieres que se refleje	El valor es estable y simple

Sobre-relacionar es un error tan real como sub-relacionar. Si "país" de un contacto nunca va a ser un registro con datos propios, hazlo un select, no una relación a una tabla "Países". Relaciona lo que de verdad es una entidad con vida propia.

Trampas comunes

Trampa 1: Mandar un nombre a un campo de relación

Qué pasa: Mandas "Acme Corp" al campo de relación. Falla, o no enlaza nada — el campo espera un ID.

Cómo evitar: Busca el registro primero (Search → Record ID / Page ID), y manda el ID al campo de relación.

Trampa 2: Esperar que una relación leída traiga el nombre

Qué pasa: Lees un registro y su campo de relación es ["rec123"]. Esperabas "Acme Corp".

Cómo evitar: Las relaciones llegan como listas de IDs. Si necesitas el dato real, haz un Get adicional con ese ID.

Trampa 3: Depender de una vista para el filtrado del workflow

Qué pasa: El workflow lee "desde la vista Pendientes". Alguien edita esa vista y el workflow empieza a procesar otros registros — sin que nadie tocara el workflow.

Cómo evitar: Pon el filtro en el workflow, explícito. No dependas de configuraciones externas.

Trampa 4: Sobre-relacionar

Qué pasa: Conviertes en relación cosas que eran simples etiquetas (estado, prioridad, país). Tu base se vuelve un laberinto de tablas.

Cómo evitar: Relaciona solo lo que es una entidad con vida propia. Lo demás, select o texto.

Trampa 5: Olvidar que escribir una relación implica un lookup previo

Qué pasa: Diseñas un workflow que "crea un pedido con su cliente" en un solo nodo, sin contar con que necesitas buscar el cliente primero.

Cómo evitar: Escribir una relación es dos pasos: buscar el registro relacionado (obtener su ID) y luego crear/actualizar con ese ID. Planéalo así.

Ejercicio: trabajar con una relación

Objetivo: practicar el patrón completo de escribir y leer una relación.

Preparación

En Airtable (o Notion), crea dos tablas relacionadas:

Empresas: con un campo nombre. Crea 2-3 empresas.
Contactos: con nombre, email, y un campo de relación empresa que apunta a Empresas.

Tu tarea

Escribir una relación: workflow que recibe un contacto con el nombre de su empresa → busca esa empresa en la tabla Empresas (Search) → crea el contacto en Contactos mapeando el campo empresa al Record ID encontrado
Verifica en Airtable/Notion que el contacto quedó realmente enlazado a la empresa
Leer una relación: workflow que lee un contacto → observa que el campo empresa viene como un ID → haz un Get de la empresa con ese ID para obtener su nombre real

Ver pistas

En el 1: el Search de Empresas te da el Record ID en su output. Ese ID es lo que va al campo de relación del Create — normalmente como una lista de un elemento.
En el 3: confirma mirando el output que empresa es ["rec..."]. El Get con ese ID te devuelve el registro completo de la empresa.
La lección: una relación siempre implica un paso de lookup — para escribirla (nombre→ID) o para leerla a fondo (ID→dato).

Resumen y siguiente paso

Vistas, filtros y relaciones son la razón de ser de subir en la escala de estructura — no funciones opcionales
Una relación conecta registros de dos tablas/bases de forma nativa y viva — a diferencia del BUSCARV frágil de Sheets
Clave para workflows: los campos de relación se manejan con IDs, no con nombres — escribir una relación implica buscar el registro primero; leerla a fondo implica un Get con el ID
Las vistas son para los humanos — un workflow casi siempre quiere los datos crudos y aplica su propio filtro
Pon el filtro en el workflow, no dependas de vistas ni filtros guardados que alguien puede cambiar — el workflow debe ser predecible
Modela como relación solo lo que es una entidad con vida propia; lo demás, select o texto
5 trampas: nombre a campo de relación, esperar nombre al leer, depender de vistas, sobre-relacionar, olvidar el lookup previo

Antes de avanzar deberías poder:

Escribir y leer un campo de relación usando IDs
Explicar por qué un workflow ignora las vistas
Decidir qué modelar como relación y qué no

Lo que sigue (cápsula 07):

Ya dominas las dos herramientas y lo que las hace especiales. La cápsula 07 cubre lo que se rompe en producción: rate limits, cambios de estructura, los problemas de cada API, y el manejo de los IDs cuando algo no cuadra. El troubleshooting de Airtable y Notion.

Recursos adicionales

Airtable: campos de enlace - Cómo funcionan las relaciones en Airtable.
Notion API: relaciones - Cómo funcionan las propiedades de relación en Notion.
Airtable / Notion: vistas - Qué son las vistas y para qué sirven (a los humanos).

Creado: Mayo 14, 2026 Versión: 1.0

← AnteriorCuándo Usar Cada Una Siguiente →Troubleshooting de Airtable y Notion