Módulo 8: Proyecto — Hub de Integraciones
Arquitectura del Hub
Descripción de la cápsula
Antes de tocar un solo nodo, hay que diseñar. Esta cápsula es de papel y lápiz — y es la más importante del módulo, porque un hub mal diseñado funciona en la demo y se vuelve inmantenible en tres meses.
El caso de negocio del capstone: una agencia (o cualquier negocio de servicios) que capta clientes potenciales por varios canales — un formulario en su web, reservas de Calendly, correos a una dirección de contacto — y necesita que cada uno de esos leads, sin importar por dónde entró, acabe en el mismo lugar: registrado en el CRM, anotado en una hoja, con el equipo avisado en Slack, y con un correo de confirmación enviado.
Esta cápsula te enseña a diseñar ese hub: las tres capas, cómo se conectan, y la decisión arquitectónica que lo define — el formato común que permite que tres entradas distintas alimenten un solo núcleo. Al final tendrás el plano completo; las cápsulas 03-05 lo construyen.
Lo que vas a aprender
Al terminar esta cápsula serás capaz de:
- ✅ Diseñar las tres capas de un hub: entrada, núcleo, distribución
- ✅ Definir un formato común — la pieza que hace que el hub escale
- ✅ Decidir entre construir el hub como un workflow o como varios
- ✅ Dibujar el plano del hub antes de construirlo
- ✅ Reconocer por qué el diseño importa más que los nodos
El caso de negocio del capstone
La agencia "Norte Digital" capta leads por tres canales:
| Canal de entrada | Qué llega |
|---|---|
| Formulario web | Un webhook con nombre, email, empresa, mensaje |
| Calendly | Una reserva — alguien agendó una llamada de descubrimiento |
| Email de contacto | Un correo a hola@nortedigital.com |
Y, sin importar por dónde entró el lead, el negocio quiere siempre lo mismo:
- Registrarlo en el CRM (HubSpot) como lead
- Anotarlo en una hoja de seguimiento (Sheets)
- Avisar al equipo en Slack
- Mandarle un correo de confirmación (Gmail)
Tres entradas, un resultado común repartido en cuatro herramientas. Ese es el hub.
El error que vamos a evitar: el hub "espagueti"
Recuerda la idea clave de la cápsula 01. La forma ingenua de construir esto:
Formulario → Set → HubSpot → Sheets → Slack → Gmail
Calendly → Set → HubSpot → Sheets → Slack → Gmail ← ¡duplicado!
Email → Set → HubSpot → Sheets → Slack → Gmail ← ¡otra vez!
Tres copias casi idénticas. Cambias el mensaje de Slack → lo cambias en tres lados. Agregas un cuarto canal → cuarta copia. Esto es el hub "espagueti", y se pudre rápido.
La forma arquitectónica:
Formulario ─┐
Calendly ─┼─→ [FORMATO COMÚN] ─→ NÚCLEO ─→ DISTRIBUCIÓN
Email ─┘ (HubSpot, Sheets,
Slack, Gmail)
Una sola copia del núcleo y la distribución. Las entradas solo traducen a un formato común. Cambias el mensaje de Slack → lo cambias una vez. Agregas un canal → agregas un traductor.
La pieza clave: el formato común
El formato común (o "contrato de datos") es lo que hace posible toda la arquitectura. Es un conjunto fijo de campos que toda entrada debe producir, sin importar de dónde venga.
Para el hub de Norte Digital, definamos el formato común — llamémoslo el "lead normalizado":
name (texto)
email (texto, minúsculas)
company (texto, o "Sin especificar")
message (texto — qué quiere el lead)
source_channel (texto — "form" | "calendly" | "email")
date (fecha-hora)
La regla de oro:
Cada punto de entrada tiene UNA tarea: producir un "lead normalizado". El webhook del formulario lo arma de su forma. El trigger de Calendly lo arma de la suya. El trigger de Gmail de la suya. Pero los tres terminan produciendo exactamente la misma estructura de seis campos.
A partir de ahí, el núcleo y la distribución no saben ni les importa de dónde vino el lead. Trabajan siempre con el mismo formato.
Esto es lo que viste en pequeño en el Módulo 1 (normalizar con un Set) y el Módulo 7 (aplanar el payload de Calendly). El hub lo eleva a principio de arquitectura: la normalización no es un detalle, es la frontera entre la capa de entrada y el resto del sistema.
El campo source_channel es importante: el núcleo no necesita saber de dónde vino para procesar, pero sí conviene guardarlo — para reportes ("¿cuántos leads vienen de Calendly?") y por si alguna lógica de distribución quiere variar según el origen.
Las tres capas, en detalle
Capa 1: Puntos de entrada (cápsula 03)
Tres triggers, tres workflows pequeños (o tres ramas), cada uno con una sola misión: recibir lo que llega por su canal y traducirlo al lead normalizado. Nada más. No registran, no avisan — solo traducen y entregan.
Capa 2: Núcleo de procesamiento (cápsula 04)
Recibe un lead normalizado (no sabe de dónde vino) y lo prepara:
- Deduplica — ¿este lead ya existe? (buscar antes de actuar, M01)
- Enriquece — ¿se le puede agregar algo? (la fecha, una clasificación)
- Enruta — ¿todos los leads se tratan igual, o algunos van por un camino distinto?
Capa 3: Distribución (cápsula 05)
Toma el lead procesado y lo reparte a las cuatro herramientas: HubSpot, Sheets, Slack, Gmail. No sabe cómo se procesó — solo distribuye.
¿Un workflow o varios?
Una decisión de diseño real. Dos enfoques:
| Enfoque | Cómo | Cuándo |
|---|---|---|
| Todo en un workflow | Las tres entradas, el núcleo y la distribución en un solo lienzo | Hubs simples; más fácil de ver de un vistazo |
| Varios workflows conectados | Cada entrada es un workflow que llama a un workflow "núcleo+distribución" común (subworkflow) | Hubs que crecen; el núcleo se mantiene una sola vez de verdad |
Recomendación: para este capstone, empieza pensando en un workflow con tres ramas de entrada que convergen (con un nodo Merge) en el núcleo. Es más fácil de entender y construir. Pero ten presente que, en producción, el patrón de subworkflow (un workflow "núcleo" que las tres entradas invocan) es el que de verdad cumple la promesa de "una sola copia del núcleo". Lo mencionamos en la cápsula 07 como evolución.
El plano del hub
Júntalo todo. Este es el plano que vas a construir en las cápsulas 03-05:
┌─ ENTRADA ────────────────┐
│ Webhook (formulario) ─┐ │
│ Calendly Trigger ─┼──┼─→ cada uno produce un
│ Gmail Trigger ─┘ │ LEAD NORMALIZADO
└─────────────────────────┘ (6 campos fijos)
│
▼ (los tres caminos convergen)
┌─ NÚCLEO ─────────────────┐
│ • Deduplicar (¿existe?) │
│ • Enriquecer (fecha...) │
│ • Enrutar (¿caso especial?)
└─────────────────────────┘
│
▼
┌─ DISTRIBUCIÓN ───────────┐
│ → HubSpot (registrar) │
│ → Sheets (anotar) │
│ → Slack (avisar) │
│ → Gmail (confirmar) │
└─────────────────────────┘
Tres entradas, un núcleo, cuatro salidas. La forma de reloj de arena de la cápsula 01.
Trampas comunes
Trampa 1: Construir antes de diseñar
Qué pasa: Abres n8n y empiezas a poner nodos. A la tercera entrada, el workflow es un caos.
Cómo evitar: Diseña el plano primero, en papel. Esta cápsula es ese paso — no la saltes.
Trampa 2: No definir el formato común
Qué pasa: Cada entrada produce campos con nombres distintos. El núcleo tiene que manejar tres formatos. Toda la arquitectura se cae.
Cómo evitar: El formato común es la pieza central. Defínelo explícitamente — los seis campos del "lead normalizado" — antes de construir nada.
Trampa 3: Meter lógica de negocio en los puntos de entrada
Qué pasa: El webhook del formulario, además de traducir, también registra en HubSpot "ya que está". Ahora esa lógica solo aplica a ese canal.
Cómo evitar: Los puntos de entrada solo traducen. Toda la lógica de negocio vive en el núcleo y la distribución — donde aplica a todos los canales.
Trampa 4: Diseñar para los canales de hoy y nada más
Qué pasa: Diseñas el hub tan pegado a los tres canales actuales que agregar un cuarto exige rehacerlo.
Cómo evitar: El formato común te protege: si el núcleo solo conoce el "lead normalizado", un canal nuevo es solo un traductor más. Diseña pensando en "¿y si mañana hay un cuarto canal?".
Ejercicio: diseña tu plano
Objetivo: producir el plano del hub antes de construir nada.
Tu tarea
En papel (o en una nota — sin n8n todavía):
- Dibuja las tres capas del hub de Norte Digital: entrada, núcleo, distribución.
- Escribe el formato común — los campos exactos del "lead normalizado". ¿Son los seis que propusimos, o tu caso necesita otro?
- Para cada punto de entrada, anota: ¿qué llega por ese canal y cómo se traduce a cada campo del formato común? (Ej.: en Calendly, el "mensaje" sale de la respuesta del formulario de reserva.)
- Decide: ¿lo construyes como un workflow con ramas que convergen, o como subworkflows? Justifica.
Ver pistas
- En el 3, el ejercicio revelador: cada canal trae los datos "en bruto" de forma distinta, pero los tres deben llenar los mismos seis campos. Donde un canal no tenga un dato (ej. el email de contacto quizás no trae "empresa"), ahí va el valor por defecto.
- En el 4, para aprender: un workflow con ramas convergentes es más visual. Para producción real: subworkflows. No hay respuesta única — lo importante es justificarla.
Resumen y siguiente paso
- Diseñar va antes que construir — un hub mal diseñado funciona en la demo y se pudre en tres meses
- El caso: una agencia capta leads por tres canales y quiere el mismo resultado en cuatro herramientas
- El error a evitar: el hub "espagueti" — duplicar todo el flujo por cada canal
- La pieza clave: el formato común ("lead normalizado", 6 campos fijos) — cada entrada tiene una tarea: producirlo
- A partir del formato común, el núcleo y la distribución no saben ni les importa de dónde vino el lead
- Las tres capas: entrada (traduce) → núcleo (deduplica, enriquece, enruta) → distribución (reparte)
- Un workflow con ramas convergentes para aprender; subworkflows para producción
- 4 trampas: construir antes de diseñar, no definir el formato común, meter lógica en las entradas, diseñar solo para los canales de hoy
Antes de avanzar deberías poder:
- Dibujar las tres capas de un hub
- Definir un formato común para tu caso
- Explicar por qué el formato común hace que el hub escale
Lo que sigue (cápsula 03):
Tienes el plano. Empezamos a construir por la primera capa: los puntos de entrada. Tres triggers distintos, cada uno con la única misión de producir un "lead normalizado" — y el nodo que hace que los tres caminos converjan en uno solo.
Recursos adicionales
- n8n Merge node Docs - Para hacer converger las ramas de entrada.
- n8n: subworkflows - El patrón para un núcleo "una sola copia".
- Revisa la STRATEGY de esta guía — la "Decisión 3" describe este hub no-lineal.
Creado: Mayo 14, 2026 Versión: 1.0