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.
Top comments (0)