Expresiones en n8n: transformar datos sin romper el workflow

La mayoría de los fallos en una automatización n8n no vienen del conector. Vienen de asumir que los datos siempre tienen la misma forma.

Respuesta rápida

Las expresiones de n8n sirven para leer y transformar valores dinámicos dentro de un workflow: el email de un formulario, el importe de una factura, el teléfono de un lead, una fecha de reserva o el resultado devuelto por una API. La regla práctica es sencilla: normaliza los datos pronto, valida lo obligatorio, evita truncar arrays sin querer y usa Code solo cuando sea más claro que una cadena de expresiones.

Qué es una expresión en n8n

Una expresión es una pequeña instrucción dentro de un campo de n8n que calcula un valor a partir de los datos del workflow. Puede leer el item actual, consultar un nodo anterior, concatenar texto, convertir formatos, elegir un valor alternativo o preparar el payload que enviarás a otra herramienta.

La referencia base está en la documentación oficial de expresiones de n8n. Para entender cómo viajan los datos entre nodos, conviene leer también la documentación oficial de data mapping.

Por qué importan en una empresa

Un workflow real rara vez recibe datos perfectos. Un formulario puede mandar telefono, una API puede mandar phone, un Excel puede traer Teléfono cliente y una integración de WhatsApp puede incluir prefijo, espacios o símbolos. Si cada nodo usa el formato original, el workflow se vuelve frágil.

Las expresiones permiten convertir esa variedad en un modelo interno estable. Así, el resto del flujo trabaja con campos previsibles:

{
  "name": "Ana Pérez",
  "email": "ana@example.com",
  "phone": "+34600000000",
  "source": "landing-seo-madrid",
  "intent": "presupuesto"
}

Cuando tienes ese modelo, puedes enviar el lead al CRM, crear una tarea, responder por email, lanzar una revisión manual o preparar una factura sin repetir lógica en cada paso.

El item actual y $json

Si un nodo recibe:

{
  "customer": {
    "name": "Ana",
    "email": "ana@example.com"
  },
  "total": 125.5
}

puedes leer:

{{$json.customer.name}}
{{$json.customer.email}}
{{$json.total}}

$json representa el JSON del item actual. Esa frase parece simple, pero explica muchos errores. Si el nodo recibe varios items, cada ejecución trabaja sobre su propio item. Si el campo no existe, la expresión puede fallar o devolver vacío según cómo la escribas.

Referenciar nodos anteriores

En muchos workflows necesitas leer datos de un nodo previo. Por ejemplo: recibes un formulario, consultas una API y después quieres enviar una respuesta usando datos de ambas fuentes. n8n permite referenciar salidas de otros nodos, pero hay que hacerlo con cuidado.

Antes de usar una referencia cruzada, pregúntate:

• ¿el nodo anterior siempre se ejecuta?
• ¿devuelve uno o varios items?
• ¿qué ocurre si no encuentra resultado?
• ¿qué campo exacto necesito conservar?
• ¿puedo copiar ese dato al modelo normalizado antes?

La respuesta casi siempre es normalizar antes. Si al principio guardas lead.email, lead.phone, lead.source y lead.intent, los nodos posteriores no necesitan recordar de dónde venía cada dato.

Normaliza al principio

Dos formularios pueden llamar al mismo dato email, correo o contact.email. Convierte pronto esos formatos en un modelo común:

{
  "name": "Ana",
  "email": "ana@example.com",
  "source": "landing",
  "externalId": "lead_123"
}

El resto del workflow deja de conocer las rarezas de cada origen.

En una empresa, esta decisión ahorra mantenimiento. Cuando mañana cambie el formulario, solo actualizas la normalización. El CRM, el email, el informe y la alerta de WhatsApp siguen esperando la misma estructura.

Valores ausentes

Un acceso profundo falla si parte de la ruta no existe. Puedes usar acceso opcional:

{{ $json.customer?.email ?? '' }}

Pero no conviertas un error de negocio en silencio. Si email es obligatorio, la salida correcta no es una cadena vacía: es una rama de validación que detenga o derive el item.

Una buena práctica es separar tres casos:

• campo obligatorio ausente;
• campo opcional ausente;
• campo presente pero con formato inválido.

No son el mismo problema. Un teléfono opcional vacío puede seguir adelante. Un email obligatorio vacío debe bloquear el envío al CRM. Un importe con coma decimal puede transformarse, pero un importe con texto libre necesita revisión.

Arrays

Una API puede devolver:

{
  "orders": [
    { "id": "A1", "total": 80 },
    { "id": "A2", "total": 140 }
  ]
}

Decide si quieres:

• obtener el primer elemento;
• dividir la lista en items;
• filtrar pedidos;
• calcular un agregado;
• conservar el array.

No uses [0] por costumbre: perderías el resto.

Cuándo dividir una lista en items

Si una API devuelve diez pedidos y necesitas crear diez filas, conviene convertir cada pedido en un item. Si necesitas calcular un resumen para un email interno, quizá conviene conservar el array y generar un texto agregado.

La decisión depende del destino:

El error típico es mezclar ambos modelos. Un workflow empieza item a item, luego intenta enviar un resumen y termina duplicando mensajes.

Fechas y zonas horarias

Guarda fechas de intercambio en ISO 8601 con zona. Convierte a la zona del negocio solo para mostrar o aplicar reglas que realmente dependan de ella.

Prueba cambios de día, horario de verano, valores vacíos y timestamps sin zona. Una factura enviada “mañana” puede ser un error de conversión, no de programación.

Para negocios de Madrid, define si la lógica opera en Europe/Madrid y documenta qué sistemas envían UTC. Si el proveedor manda 2026-07-30T10:00:00Z, no lo trates como hora local sin convertir.

Números, moneda y decimales

Los precios dan problemas porque cada sistema usa formato distinto. Puedes recibir:

99
99.00
99,00
99 €
"99 euros"

No envíes eso directamente a facturación. Primero convierte a número, decide moneda, valida mínimo y máximo, y conserva el valor original si necesitas auditoría.

Un flujo de facturas debería distinguir:

• subtotal;
• impuestos;
• total;
• moneda;
• concepto;
• cliente;
• identificador externo.

Si un dato falta, es mejor crear una tarea de revisión que emitir una factura incorrecta.

Texto y limpieza básica

Los formularios reciben espacios, mayúsculas, emojis, acentos y nombres escritos con prisa. Una expresión puede limpiar entradas simples:

• recortar espacios;
• convertir email a minúsculas;
• normalizar teléfono;
• eliminar saltos de línea duplicados;
• limitar longitud de una nota.

No uses la limpieza para esconder problemas. Si una nota de formulario llega vacía y es el campo que explica qué quiere el cliente, el workflow debe pedir revisión o responder solicitando más contexto.

Booleanos y decisiones

Muchos sistemas mandan true, "true", "sí", "1" o "on". Si una condición depende de eso, normaliza a booleano real antes del If.

Ejemplo de decisión:

• wantsCall = true
• hasBudget = false
• isUrgent = true

Con campos claros, las ramas del workflow se leen como negocio, no como una colección de parches técnicos.

Edit Fields, expresiones o Code

Un Code node debe tener entradas y salidas claras. Evita llamadas externas, secretos y lógica enorme dentro de un único bloque. Si se reutiliza, considera un subworkflow oficial.

La documentación del Code node es útil cuando una transformación ya no cabe de forma legible en campos visuales. También puedes apoyarte en el cookbook oficial de código para patrones habituales.

Señales de que una expresión se ha pasado de largo

Una expresión deja de ser buena cuando:

• ocupa varias líneas difíciles de leer;
• mezcla validación, formato y decisión;
• nadie entiende qué devuelve sin probarla;
• se repite en varios nodos;
• oculta errores con valores por defecto;
• depende de campos de cinco nodos distintos.

En ese punto, crea un nodo de normalización o un Code node pequeño. Una automatización mantenible no es la que usa menos nodos, sino la que se puede entender cuando algo falla.

Ejemplo 1: normalizar un lead de Madrid

Supongamos que un formulario manda:

{
  "nombre": "  Ana Pérez ",
  "correo": "ANA@EXAMPLE.COM",
  "telefono": "600 000 000",
  "servicio": "SEO local",
  "zona": "Chamberí"
}

El objetivo interno puede ser:

{
  "name": "Ana Pérez",
  "email": "ana@example.com",
  "phone": "+34600000000",
  "service": "SEO local",
  "city": "Madrid",
  "area": "Chamberí",
  "source": "formulario-web"
}

Con ese modelo puedes:

• crear lead en CRM;
• enviar aviso a ventas;
• añadir etiqueta de servicio;
• medir conversión;
• activar una secuencia de seguimiento.

Ejemplo 2: preparar un mensaje de WhatsApp interno

Un mensaje útil no debe volcar todo el JSON. Debe decir lo justo:

Nuevo lead SEO Madrid
Nombre: Ana Pérez
Zona: Chamberí
Servicio: SEO local
Web: example.com
Prioridad: revisar hoy

La expresión no solo transforma datos: traduce un evento técnico en una acción humana. Si el mensaje no permite decidir qué hacer, la automatización está generando ruido.

Ejemplo 3: crear una factura supervisada

Para facturación, no conviene pasar de formulario a factura emitida sin control. Un primer workflow más seguro puede:

• normalizar cliente;
• validar CIF/NIF si existe;
• comprobar importe;
• preparar borrador;
• avisar al equipo;
• dejar evidencia.

Cuando el proceso esté probado, se puede automatizar más. El salto de “automatización útil” a “automatización peligrosa” suele estar en ejecutar acciones finales sin validación.

Ejemplo 4: guardar filas en Google Sheets

Si vas a registrar leads en una hoja, decide las columnas antes:

fecha | nombre | email | teléfono | servicio | zona | origen | estado

Después convierte cada item a esa estructura. No dejes que la hoja crezca con columnas improvisadas como telefono2, phone, teléfono_form, observacionNueva. Una hoja que parece flexible al principio se vuelve inútil para medir.

Ejemplo 5: transformar respuesta de una API

Una API puede devolver muchos campos que no necesitas. Crea una capa de salida simple:

{
  "externalStatus": "paid",
  "amount": 99,
  "currency": "EUR",
  "customerEmail": "ana@example.com"
}

El workflow deja de depender de la estructura completa del proveedor. Si el proveedor cambia campos secundarios, tu flujo resiste mejor.

Pruebas mínimas

Construye casos con:

• item completo;
• campo obligatorio ausente;
• null;
• array vacío;
• caracteres no ASCII;
• fecha límite;
• número recibido como texto;
• cien items.

Fija datos anonimizados mientras desarrollas y elimina el pin antes de confundir una muestra con producción.

Matriz de pruebas útil

Antes de dar por buena una expresión, prueba:

No necesitas un laboratorio enorme para empezar. Necesitas no publicar un workflow que solo funciona con la muestra perfecta.

Logs sin filtrar datos sensibles

Los logs ayudan a depurar, pero también pueden exponer información. Evita registrar:

• tokens;
• contraseñas;
• documentos completos;
• datos médicos o legales;
• payloads enteros sin retención definida.

Guarda identificadores, estados y errores. Si necesitas conservar payloads para auditoría, define quién accede, cuánto tiempo se guardan y cómo se eliminan.

Cómo documentar una transformación

Cada transformación importante debería tener una mini ficha:

• origen;
• campos recibidos;
• modelo normalizado;
• campos obligatorios;
• reglas de formato;
• valores por defecto aceptados;
• errores posibles;
• responsable de negocio.

Esto hace que el workflow sea transferible. No depende de que la persona que lo montó recuerde cada decisión.

Expresiones para GEO/AIO

Las expresiones también pueden ayudar a contenido y visibilidad. Si recibes preguntas reales de clientes, puedes normalizarlas para alimentar una cola editorial:

{
  "question": "¿Cuánto cuesta automatizar WhatsApp?",
  "service": "automatizaciones",
  "market": "Madrid",
  "source": "lead-form",
  "approvedForContent": false
}

No se publica solo. Se clasifica, se revisa y se convierte en una respuesta útil. Para SEO y AIO, esto permite crear contenido basado en dudas reales: más extractable, más concreto y menos genérico.

Cuándo contratar ayuda

Tiene sentido pedir ayuda si:

• el flujo toca facturación;
• hay datos sensibles;
• hay más de un sistema origen;
• los errores duplican acciones;
• nadie sabe explicar el payload;
• el workflow funciona, pero nadie se atreve a tocarlo.

En esos casos, la mejora no es “meter IA”. La mejora es ordenar datos, reducir riesgo y hacer que cada automatización tenga dueño.

Checklist

• Existe un modelo interno normalizado.
• Campos obligatorios se validan explícitamente.
• Arrays no se truncan accidentalmente.
• Fechas conservan zona.
• Números y moneda se convierten antes de facturar.
• Code node tiene una responsabilidad pequeña.
• No se filtran secretos en logs.
• Hay pruebas con nulos y colecciones vacías.
• La transformación queda documentada.
• El flujo deja evidencia suficiente para depurar.

Patrones que recomendamos en producción

Entrada, normalización, validación y destino

Un workflow sano suele tener cuatro capas. La primera recibe el dato sin tocarlo. La segunda lo convierte a tu modelo interno. La tercera valida si puede avanzar. La cuarta lo envía al destino.

Webhook/Formulario/API
Normalización
Validación
CRM, ERP, WhatsApp, email o informe

Esta arquitectura evita que las expresiones aparezcan desperdigadas por todo el flujo. Si todo el mundo sabe que el dato limpio se llama lead.email, nadie tiene que perseguir si el origen lo llamó correo, emailAddress, contact.email o Email.

Nombres internos estables

Elige nombres internos y respétalos. Para leads, una base razonable puede ser:

{
  "lead": {
    "name": "",
    "email": "",
    "phone": "",
    "company": "",
    "website": "",
    "service": "",
    "city": "Madrid",
    "message": ""
  },
  "tracking": {
    "source": "",
    "campaign": "",
    "landing": "",
    "receivedAt": ""
  }
}

No hace falta que todos los campos existan siempre. Lo importante es que el workflow use el mismo vocabulario. Si mañana conectas otro formulario, solo adaptas la capa de entrada.

Error técnico y error de negocio

Un error técnico es que la API no responda. Un error de negocio es que el lead no tenga teléfono cuando el equipo lo necesita para llamar. Las expresiones ayudan a detectar ambos, pero no deben tratarlos igual.

Para un campo obligatorio, la ruta correcta puede ser:

• marcar el item como inválido;
• guardar el motivo;
• avisar al equipo;
• no crear acción final;
• responder al usuario si procede.

Para un campo opcional, puedes asignar un valor vacío o continuar sin esa parte. Esta diferencia mejora la calidad comercial. Un flujo que acepta todo parece cómodo, pero termina llenando el CRM de oportunidades imposibles de trabajar.

Errores típicos con expresiones

Convertir todo en texto

Si conviertes precios, fechas y booleanos a texto demasiado pronto, luego tendrás que deshacerlo. Mantén tipos útiles mientras el workflow trabaje con lógica.

Confiar en el primer item

Usar siempre el primer elemento de un array puede ocultar datos. Si una API devuelve varias líneas de pedido, varias reservas o varias respuestas, decide explícitamente qué hacer con cada una.

Repetir la misma expresión en diez nodos

Si copias la misma transformación por todo el workflow, cada cambio futuro será peligroso. Normaliza una vez y reutiliza el campo limpio.

Usar valores por defecto para todo

'', 0 o "desconocido" pueden parecer soluciones cómodas, pero también ocultan errores. Un importe desconocido no es cero. Un email ausente no es una cadena vacía. Una ciudad no informada no siempre es Madrid.

Mezclar reglas comerciales con formato

Formatear un teléfono no es lo mismo que decidir si el lead es válido. Si mezclas ambas cosas, nadie sabrá dónde cambiar la regla cuando ventas pida otro criterio.

Tabla de decisión rápida

Esta tabla evita una discusión recurrente: no hay una herramienta ganadora para todo. La mejor decisión es la que deja el flujo claro y recuperable.

Casos de uso muy concretos

Lead de SEO local

Un formulario de SEO puede llegar con nombre, web, teléfono, servicio y zona. La expresión convierte esos datos en un lead normalizado y añade contexto: ciudad Madrid, landing de origen, campaña y prioridad. Después el workflow crea una oportunidad, avisa a ventas y registra la conversión.

Facturas y presupuestos

Una automatización puede preparar un borrador de factura desde un formulario, una hoja o un CRM. Las expresiones convierten importes, conceptos, emails y referencias. La primera versión debe dejar revisión humana antes de emitir. Cuando el proceso esté probado, se puede automatizar más.

WhatsApp interno

Un aviso de WhatsApp no debe ser un JSON completo. Debe ser un mensaje breve con asunto, contacto, servicio, urgencia y enlace al registro. Las expresiones traducen el evento técnico en una acción clara para una persona.

Cola editorial para SEO/GEO/AIO

Las preguntas reales de clientes pueden normalizarse como candidatos editoriales: pregunta, servicio, mercado, fuente y estado de aprobación. El workflow no publica solo; deja una señal para que el equipo convierta dudas reales en artículos, FAQ o guías.

Métricas que sí importan

Una transformación de datos debería medirse con señales sencillas:

• porcentaje de items válidos;
• motivos de rechazo;
• duplicados detectados;
• tiempo hasta acción humana;
• errores por proveedor;
• registros recuperados tras fallo;
• acciones finales creadas.

Estas métricas permiten mejorar el workflow sin adivinar. Si el 30% de los leads falla por teléfono, quizá el formulario está mal diseñado. Si un proveedor duplica eventos, necesitas idempotencia. Si ventas tarda horas en responder, el problema no era técnico sino operativo.

Mini plantilla de documentación

Puedes documentar una transformación así:

Proceso: lead desde landing SEO Madrid
Origen: formulario web
Destino: CRM y WhatsApp interno
Campos obligatorios: name, email o phone, service
Campos opcionales: company, website, budget
Normalización: teléfono E.164, email minúscula, city Madrid si la landing es local
Errores: falta contacto, servicio desconocido, payload duplicado
Responsable: ventas
Revisión: mensual

La documentación no tiene que ser larga. Tiene que permitir que otra persona arregle el flujo sin romperlo.

Relación con webhooks y APIs

Las expresiones suelen vivir entre un webhook seguro y una API configurada con credenciales. El webhook recibe, la expresión ordena y la API entrega. Si una de esas tres capas está mal, el workflow será inestable.

Por eso no conviene vender “automatización con n8n” como si fuera solo arrastrar nodos. El valor real está en entender el proceso, los datos y los fallos posibles.

Revisión mensual de expresiones

Una expresión que hoy funciona puede quedarse vieja si cambia el formulario, la API o el criterio comercial. Por eso recomendamos revisar los workflows vivos una vez al mes. No se trata de rehacer todo, sino de comprobar si los datos reales siguen encajando con el modelo.

La revisión debería mirar:

• campos nuevos que nadie usa;
• campos antiguos que ya llegan vacíos;
• errores repetidos;
• ramas que nunca se ejecutan;
• valores por defecto demasiado frecuentes;
• duplicados;
• cambios en el catálogo comercial;
• cambios de moneda, impuestos o zona.

Este mantenimiento es especialmente importante cuando el flujo alimenta ventas, facturación o reporting. Si el dato entra mal, todo lo que se mida después estará contaminado.

Cómo empezar sin complicarlo

Si partes de cero, el primer objetivo no es automatizar toda la empresa. El primer objetivo es elegir un proceso pequeño y construirlo bien. Por ejemplo: normalizar leads de una landing, registrar solicitudes de WhatsApp, preparar borradores de factura o avisar al equipo cuando entra una oportunidad concreta.

Empieza con pocos campos, un destino, una validación y una alerta. Cuando el flujo tenga evidencia real, añade más pasos. Este enfoque evita dos errores: quedarse en teoría o montar una automatización enorme que nadie se atreve a mantener.

CTA

Sigue con webhooks en n8n paso a paso, configurar una API en n8n o n8n en producción: seguridad y errores.

Si tu empresa ya copia datos entre formularios, WhatsApp, hojas de cálculo, CRM o facturación, podemos revisar un proceso concreto y proponer una primera automatización. No hace falta empezar con una arquitectura enorme: un flujo básico desde 99 euros puede normalizar datos, validar errores y ahorrar trabajo manual desde el primer mes.