Carril: APRENDER.
Reformulación rápida
Clase 6 = pasar de datos fake a datos reales, y aprender dónde filtrar para que el workflow no se ensucie. Output: entender bien Form Trigger + Set + Filter como capa de entrada.
Clase 6 — Configuración de formularios y filtros en n8n
Esta clase es un punto de inflexión:
dejás de “probar lógica” y empezás a recibir inputs del mundo real.
1️⃣ Lo que enseña el curso (fiel al contenido)
A. El Form Trigger como entrada real
- Se usa el Form Trigger nativo de n8n
- Tiene URL de test (para vos) y URL de producción (para usuarios)
- Define campos obligatorios con tipo correcto:
- nombre → texto
- email → email
- mensaje → textarea
👉 El trigger reemplaza definitivamente al trigger manual.
B. Probar con datos reales
- Abrís la URL de test
- Enviás el formulario
- El trigger se pone verde
- Los datos ya existen en el flujo
👉 Regla implícita: no sigas si el trigger no funciona.
C. Mapear datos dinámicos con Set
- Se eliminan los valores hardcodeados
- Se arrastran campos desde el Form Trigger
Set queda como adaptador de entrada
👉 Resultado: el flujo deja de depender de datos escritos a mano.
D. Validar lógica con If
- El
If ahora evalúa datos reales
- Se confirma que la rama correcta se active
- Mismo criterio que antes (“contiene demo”, etc.)
E. Filtrar leads con Filter
- Se inserta un Filter entre nodos
- Ejemplo del curso:
- bloquear emails que contengan @platzi.com
- condición:
string → does not contain
👉 Leads que no cumplen → no siguen en el flujo.
2️⃣ Lectura crítica (producto + frontend senior)
Acá está lo importante 👇
🧠 El Form Trigger es tu API pública
Aunque parezca un formulario simple:
- define contrato de entrada
- define tipos
- define obligatoriedad
👉 Es lo mismo que diseñar:
- un endpoint
- un schema
- un DTO
Mal formulario = mal sistema aguas abajo.
⚠️ Regla implícita clave
Todo lo que entra es sospechoso hasta que se filtre.
El curso lo muestra con dominios, pero aplica a:
- spam
- datos incompletos
- inputs internos
- pruebas de QA
🧠 Set no es un “paso más”
Es una capa de normalización.
Buenas prácticas implícitas:
- mapear una sola vez
- renombrar ahí
- no repetir lógica en nodos de acción
En frontend sería:
- adapter
- mapper
- serializer
🧠 Filter vs If (distinción clave)
Aunque se parecen:
- Filter → corta el flujo (gatekeeper)
- If → bifurca el flujo (routing)
👉 Producto:
- Filter = “esto no entra al sistema”
- If = “esto entra, pero va por otro camino”
Muchísima gente los mezcla.
⚠️ Riesgo no dicho
Si filtrás demasiado tarde:
- gastás recursos
- ensuciás logs
- disparás acciones innecesarias
👉 Filtrar lo antes posible es diseño defensivo.
🧠 Detalle importante (self-hosted)
Lo que aparece en comentarios:
- si el Form Trigger no abre
- suele ser por
WEBHOOK_URL mal configurada
No es n8n “fallando”: es infra mal declarada.
Núcleo de la clase (3 bullets)
- El Form Trigger define tu contrato de entrada.
Set convierte datos externos en datos del sistema.
Filter protege el flujo del ruido.
Mini checklist mental (rápido)
Antes de seguir:
- ¿los campos tienen tipo correcto?
- ¿hay algo que debería filtrarse antes?
- ¿el
Set es el único lugar donde mapeo datos?
Si dudás en alguno → hay deuda.
Cierre
Qué debería quedarte claro
- Esta clase no es “formularios”: es control de frontera.
- Un buen workflow empieza filtrando, no actuando.
- Lo que entra mal, rompe todo después.
Punto ciego típico
Pensar “esto después lo arreglo con IA / If / lógica”.
No: la calidad se define en la entrada.