DEV Community: Awakate

Qué registrar cuando falla una automatización antes de volver a ejecutarla

Juan Carlos Carpio Cámara — Fri, 30 Oct 2026 18:05:55 +0000

Un flujo puede fallar después de haber hecho parte del trabajo. Quizá ha creado una ficha en el CRM, pero no ha enviado la confirmación. Si solo guardas un mensaje como "ha ocurrido un error", después tendrás que adivinar qué se puede repetir.

Antes de añadir más reintentos, define el registro que permitirá revisar una ejecución.

1. Identifica la operación, no solo el intento

Guarda un identificador de la operación de negocio y otro de la ejecución. El primero permite reconocer que dos intentos pertenecen al mismo alta o solicitud. El segundo ayuda a investigar qué ocurrió en una ejecución concreta.

Si guardas un identificador de cliente, usa el mínimo necesario. El registro de errores no necesita una copia completa de sus datos.

2. Anota el último paso confirmado

Para una secuencia formulario, CRM y correo, distingue al menos estos estados:

Paso	Qué registrar
Recepción	Identificador de operación y fecha
CRM	Si se ha confirmado la escritura y referencia del registro
Correo	Si el proveedor ha aceptado el envío y su referencia, cuando exista
Revisión	Motivo, persona responsable y estado de resolución

Que una petición haya salido no demuestra que el servicio remoto no la haya ejecutado. Si se pierde la respuesta, el resultado puede ser desconocido. Comprueba el estado remoto antes de repetir una acción con efectos externos.

Un registro que permite decidir

Ejemplo ficticio: el CRM confirmó la creación de una ficha. El proveedor de correo rechazó la autenticación antes de aceptar el mensaje de bienvenida.

Campo	Ejemplo ficticio	Para qué sirve
Operación	alta_demo_1042	Reconocer el alta aunque tenga varios intentos
Ejecución	intento_demo_03	Identificar este intento concreto
Último paso confirmado	CRM, ficha demo_582	Conservar la referencia de lo que ya existe
Correo	No aceptado, error de autenticación	Separar un rechazo conocido de un resultado incierto
Estado	Revisión pendiente	Hacer visible que requiere una intervención
Siguiente acción	Corregir el acceso y reanudar el envío	Evitar volver a crear la ficha del CRM

No necesitas copiar el nombre, el correo o los documentos del cliente a este registro de errores. Usa una referencia interna con acceso restringido a los datos que hagan falta para resolver el caso.

Si el proveedor aceptó el mensaje y después se perdió la respuesta, la decisión cambia: el envío queda incierto. Consulta la referencia que admita ese proveedor o deriva a revisión; volver a enviarlo sin comprobar puede duplicarlo.

3. Separa lo temporal de lo que necesita una corrección

Un límite de peticiones puede admitir espera y reintento. Una credencial revocada o un campo obligatorio ausente requieren otra acción. No conviene usar la misma política para ambos casos.

Registra la clase de error, el número de intentos y la siguiente acción. Si el resultado es desconocido, indícalo; no lo conviertas automáticamente en un fallo sin efectos.

4. Deja una salida para la revisión humana

Cuando se alcance el límite de intentos, el caso debe quedar visible para una persona. Un registro útil explica qué operación está pendiente, qué se ha confirmado y qué decisión falta.

Para reanudar, confirma primero que la operación no se completó por otra vía. Después recupera desde el paso seguro y conserva el resultado de la revisión.

5. Prueba el fallo después de cada escritura externa

No pruebes solo el recorrido correcto. Simula una respuesta perdida después de la escritura en CRM y comprueba que la recuperación no crea otra ficha. Haz lo mismo con el envío del correo.

Cómo encaja en n8n

n8n permite asignar un workflow de errores a otro workflow y usar Error Trigger para tratar una ejecución fallida. Ese aviso ayuda a detectar el fallo; la recuperación necesita también el estado de la operación de negocio que has definido.

La información del error varía según dónde ocurra. No presupongas que siempre habrá una URL o un identificador de ejecución: la documentación indica que dependen de que la ejecución se haya guardado y pueden faltar en errores del trigger. Diseña una salida para esos casos.

Referencia: manejo de errores en la documentación oficial de n8n.

La herramienta concreta puede cambiar. La pregunta es la misma: ¿qué sabemos que ya ocurrió y qué podemos repetir sin producir un efecto extra?

Si estás definiendo el proceso completo, esta guía para automatizar el alta de clientes sirve como contexto para ordenar los pasos antes de conectarlos.

Este contenido se ha preparado con ayuda de inteligencia artificial. Los datos del ejemplo son ficticios. Es un patrón de diseño; no incluye un workflow ejecutable ni resultados medidos de una implantación.

Webhooks en n8n: evita duplicados al conectar tu CRM

Juan Carlos Carpio Cámara — Wed, 28 Oct 2026 21:56:44 +0000

Un formulario envía una consulta. La conexión tarda. El origen repite la entrega y aparecen dos oportunidades en el CRM.

Hay otro fallo menos visible: la ejecución termina sin errores, pero durante la transformación desaparece el campo que explicaba qué necesitaba esa persona.

Este ejemplo es didáctico. Propone una forma de revisar esas dos situaciones antes de activar una integración. No describe una implantación medida ni una plantilla lista para importar.

1. Define qué entrega estás procesando

Empieza por el identificador del evento o envío que proporciona el origen. Combínalo con el sistema y la cuenta de procedencia cuando haga falta para evitar colisiones.

Por ejemplo, una clave puede identificar la cuenta, el formulario y el envío envio_001. Si el proveedor vuelve a entregar ese mismo envío, la clave debe mantenerse.

El correo de la persona cumple otra función. Una misma persona puede enviar una consulta hoy y otra distinta mañana. Bloquear cualquier envío que repita correo puede ocultar una petición legítima.

Si el origen no ofrece un identificador estable, hay que diseñar esa identificación. Un hash del contenido o una ventana de tiempo son alternativas con compromisos: pueden confundir dos consultas iguales que sí eran independientes. Documenta esa decisión antes de automatizarla.

2. Conserva los campos que importan

Escribe una tabla pequeña con tres columnas: campo recibido, campo normalizado y destino.

Recibido	Normalizado	Destino
Identificador del envío	`event_key`	Registro de procesamiento
Correo	`email`	Contacto del CRM
Motivo de la consulta	`request_summary`	Oportunidad o nota
Página del formulario	`entry_page`	Origen de la consulta

El campo de origen puede perderse si el paso de normalización conserva solo nombre y correo. La llamada siguiente puede ser válida aunque la información llegue incompleta.

Prueba con valores ficticios que puedas reconocer después. Comprueba el resultado en el registro final, además de mirar los datos recibidos por el webhook. Define qué campos ausentes deben detener el proceso y cuáles pueden quedar vacíos.

3. Registra la recepción antes de darla por aceptada

Guarda la clave y un estado de procesamiento en un registro persistente. Para evitar que dos ejecuciones simultáneas acepten la misma entrega como nueva, la exclusión debe aplicarse de forma atómica.

Una base de datos con una restricción única sobre la clave es una posibilidad. En PostgreSQL, ON CONFLICT permite decidir qué hacer cuando una inserción encuentra un conflicto. Consultar primero y escribir después, sin protección adicional, deja una carrera entre ambas operaciones.

Después, una sola ejecución debe obtener el derecho a procesar el evento. Las demás consultan su estado y no repiten la creación. Si se interrumpe el procesamiento, debe existir una recuperación definida; un estado "procesando" no puede bloquearlo para siempre.

Si respondes al origen antes de terminar, hazlo después de guardar de forma duradera lo que has aceptado. En n8n puedes configurar cuándo responde el Webhook. Una respuesta HTTP de recepción y un alta terminada en el CRM son estados diferentes.

4. Resuelve el resultado incierto antes de repetir

Imagina que la petición al CRM termina con un timeout. El CRM podría haber creado la oportunidad y haberse perdido la respuesta.

Repetir la creación inmediatamente puede duplicarla.

Si la API de destino admite claves de idempotencia, utiliza el mecanismo documentado por ese proveedor. No basta con añadir una cabecera que el servidor no reconoce.

Si admite una referencia externa consultable, guarda y busca esa referencia para conciliar el resultado antes de volver a escribir. Si no ofrece ninguna de esas garantías, deriva el caso incierto a revisión o diseña otra integración. Un registro local, por sí solo, no garantiza una única escritura en dos sistemas distintos.

El estado "completado" debe reflejar un resultado confirmado. Para el resto, distingue error recuperable, resultado incierto y revisión pendiente. Cada uno necesita una salida clara.

5. Prueba las excepciones de forma deliberada

Estas son las comprobaciones que usaría antes de activar el flujo. Son resultados esperados, no pruebas ejecutadas sobre este ejemplo.

Situación	Resultado esperado
Entrega nueva y válida	Se registra y llega al CRM con todos los campos necesarios
Misma entrega repetida	Se consulta su estado sin crear otra oportunidad
Dos copias simultáneas	Solo una obtiene el derecho a procesarla
Mismo correo con otro identificador de envío	Se evalúa como consulta nueva
Timeout después de enviar al CRM	Se concilia el resultado antes de repetir la escritura
Falta un campo obligatorio	Se registra un motivo claro y no se crea un alta incompleta
Interrupción tras reservar el evento	La recuperación detecta el trabajo pendiente y aplica la política definida

Usa datos sintéticos durante estas pruebas. El registro técnico necesita explicar qué pasó, sin copiar por defecto todo el contenido personal del formulario.

Del webhook al proceso completo

Estas comprobaciones cubren la entrega técnica. El alta también incluye qué información se pide, quién revisa las excepciones y qué ocurre después de crear la ficha. La guía del proceso de alta de clientes desarrolla ese contexto.

Antes de activar tu integración, elige uno de los fallos de la tabla y fuerza esa situación en un entorno de prueba. Comprueba qué queda registrado y cómo se recupera el proceso.

Referencias técnicas

Este texto se ha preparado con ayuda de IA. Presenta un patrón de diseño y ejemplos didácticos; no incluye un flujo ejecutable ni resultados de una prueba de producción.