Automatizar pedidos con n8n sin perder el control de los errores

Automatizar pedidos con n8n es una de las formas más rápidas de quitar trabajo manual a un ecommerce. Entra un pedido en la tienda y, sin que nadie intervenga, llega al ERP, se registra en el CRM, se avisa a almacén y sale la comunicación al cliente. Los problemas empiezan cuando algo falla a mitad de camino: un flujo mal planteado puede dejar pedidos a medias, repetir facturas o mandar el mismo correo tres veces sin que nadie se entere.

Cuando un workflow falla, debería decir qué pedido, en qué paso y qué hay que hacer.

Define los estados del pedido antes de abrir el editor

Antes de abrir el editor, dibuja el proceso en papel: qué estados atraviesa un pedido, qué sistemas intervienen y quién tiene que enterarse si algo no termina. Un workflow que conecta la tienda con correo, CRM y ERP es una pequeña aplicación de negocio y necesita el mismo rigor que cualquier otra.

Imagina una tienda que automatiza el paso de pedidos al ERP y el envío de un correo de confirmación personalizado. Un día el ERP no responde. Si el flujo se detiene sin más, nadie sabe qué pedidos quedaron pendientes; si se reintenta entero, el cliente recibe el correo dos veces. Las dos situaciones se evitan diseñando antes.

En nuestros proyectos de automatizaciones n8n empezamos siempre por esa secuencia de estados y por el responsable de cada excepción.

Cómo automatizar pedidos con n8n: disparador y entradas

Elige el disparador

• Un webhook, con el que la tienda notifica cada pedido en tiempo real. Es rápido, pero tienes que contar con que llegue repetido o desordenado.
• Una tarea programada que consulta cada cierto tiempo los pedidos nuevos. Es más predecible y más fácil de recuperar, a cambio de algo de latencia.
• La ejecución manual, útil en procesos que requieren una decisión previa o para reprocesar casos concretos.

A menudo lo que mejor funciona es combinarlos: el webhook como vía rápida y una tarea programada de reconciliación que detecte los pedidos que se quedaron sin procesar.

Valida antes de tocar nada

Antes de crear o modificar datos en otro sistema, comprueba que el pedido trae lo que necesitas: identificador, origen, cliente, líneas, importes y método de envío. Un nodo condicional al principio del flujo puede separar los pedidos válidos de los incompletos.

Si falta algo, detén el proceso con un mensaje claro en vez de avanzar con datos parciales. Un pedido incompleto en el ERP cuesta más de corregir que uno que espera revisión.

Qué pasos se pueden reintentar y cuáles no

n8n permite configurar reintentos en los nodos (número de intentos y espera entre ellos, según la versión). Ayuda mucho, pero activarlos en todos los nodos sin pensar es peligroso. Distingue dos tipos de operación:

• Las idempotentes, como leer un catálogo, consultar el estado de un pedido o actualizar un campo con el mismo valor. Repetirlas no hace daño.
• Las que tienen efectos secundarios: crear un pedido en el ERP, emitir una factura, cobrar, enviar un correo o un SMS. Si las repites, duplicas el efecto.

En estas últimas, antes de reintentar hay que comprobar si el pedido ya existe en el ERP o si el correo ya salió. Si guardas el identificador del pedido junto al resultado de cada paso, en el sistema destino o en una tabla de control, el reintento sabe por dónde seguir.

Es el mismo principio de idempotencia que evita duplicados en cualquier integración ERP ecommerce, con n8n o sin él.

Errores transitorios y definitivos

Un timeout o un servicio no disponible pueden resolverse solos en unos minutos. Un producto que no existe en el ERP o un campo obligatorio vacío seguirán igual por mucho que reintentes. Separa los dos casos con una condición sobre el tipo de error y manda los definitivos directamente a revisión.

Workflow de errores y alertas útiles

En n8n puedes asociar a un flujo un workflow de errores que se ejecuta cuando la ejecución falla. Úsalo para centralizar las incidencias en lugar de configurar avisos sueltos en cada nodo. Ese workflow debería:

• Identificar el flujo, la ejecución y el pedido afectado.
• Indicar qué nodo falló y con qué mensaje.
• Mandar el aviso al canal que el equipo mira de verdad, sea el correo, el chat interno o la herramienta de tickets.
• Registrar la incidencia en una cola revisable, para no depender de que alguien lea un mensaje a tiempo.

Una automatización de pedidos madura convierte esa cola en un listado de excepciones con su estado: pendiente, en revisión o resuelto.

Cuándo debe entrar una persona

Hay decisiones que conviene dejar en manos de alguien: cambiar cantidades, desbloquear un pedido retenido por posible fraude, aplicar un descuento excepcional o enviar documentación definitiva al cliente. Diseña ese punto de forma explícita y deja resuelto:

• Quién recibe el aviso y quién le sustituye si no está.
• Qué información necesita para decidir sin tener que abrir cinco sistemas.
• Cómo sigue el flujo tras aprobar o rechazar, por ejemplo con un enlace que reanuda la ejecución o con un cambio de estado que detecta otro flujo.
• Qué pasa si nadie responde en un plazo razonable.

Cuando el punto de aprobación está mal diseñado se convierte en un cuello de botella, y el equipo acaba saltándoselo y haciendo las cosas a mano.

Logs útiles sin guardar datos de más

El historial de ejecuciones de n8n sirve para depurar, pero no sustituye a un registro pensado para negocio. Los logs deben contar qué flujo se ejecutó, para qué pedido, qué paso falló y cómo terminó. Para eso no hace falta guardar la dirección completa del cliente ni el contenido íntegro de cada petición.

• Revisa cuánto tiempo se conservan las ejecuciones y quién puede verlas.
• Evita que el historial almacene datos personales innecesarios.
• Guarda las credenciales en el gestor de credenciales, nunca en nodos de código, capturas, logs ni exports compartidos.
• Deja el acceso al editor solo a quien mantiene los flujos.

Documentación para mantener el flujo

Un workflow que solo entiende quien lo construyó es un riesgo. Al terminar, pide o prepara:

• Un diagrama simple del flujo y sus estados.
• Instrucciones para pausar el proceso sin perder pedidos.
• Un procedimiento para reprocesar errores de forma segura.
• Cómo rotar credenciales y qué flujos se ven afectados.
• Nombres de nodos descriptivos y notas en los pasos que no sean evidentes.

Con el tiempo los flujos crecen y se conectan entre sí. Revisarlos de vez en cuando forma parte de un buen mantenimiento ecommerce, igual que actualizar plugins o vigilar el rendimiento. Si todavía no sabes qué procesos automatizar primero, una visión global de automatización ecommerce te ayuda a ordenarlos por impacto.

Checklist antes de activar el flujo

• Los estados del pedido y los responsables de cada excepción están definidos.
• Las entradas se validan antes de modificar datos en otros sistemas.
• Los reintentos solo están activos en pasos idempotentes o precedidos de comprobación.
• Hay un workflow de errores que identifica pedido, paso y acción.
• Los puntos de aprobación humana tienen responsable y plazo.
• Los logs no guardan datos personales innecesarios ni credenciales.
• Existe documentación para pausar, reprocesar y rotar credenciales.