Cuando una integración falla, repetir la ejecución no siempre la recupera: puede crear dos tareas, enviar dos avisos o actualizar dos veces el mismo registro. Un diseño fiable necesita identificar cada operación, hacer segura su repetición cuando sea posible, limitar los reintentos y reconciliar los casos cuyo resultado no se conoce.
La secuencia útil es: evento → identificador → efecto esperado → estado → tipo de fallo → reintento o parada → reconciliación. No garantiza que nunca haya duplicados o pérdidas. Permite detectar el estado dudoso y decidir cómo resolverlo sin confiar en que “volver a ejecutar” arreglará todo.
Decide primero qué operación no debe repetirse
“El workflow” suele ser una unidad demasiado grande. Dentro de un mismo flujo puede haber varios efectos:
- crear o actualizar un contacto;
- abrir una oportunidad;
- generar una tarea;
- reservar una cita;
- enviar una comunicación;
- registrar un cobro o una devolución.
Cada efecto necesita su propia identidad y su propio estado. Si el flujo recibe dos veces el mismo webhook, actualizar un dato puede ser inocuo mientras crear una tarea nueva no lo sea.
Escribe una frase concreta: «Para el evento X, el sistema debe aplicar el efecto Y una sola vez desde el punto de vista del proceso». Después define qué dato demuestra que dos entradas representan el mismo evento. Puede ser un identificador del proveedor, una referencia de operación o una clave derivada de atributos estables. Si la clave cambia en cada intento, no permite reconocer la repetición.
Tres tipos de fallo que no admiten la misma respuesta
Fallo transitorio
El servicio está temporalmente ocupado, corta la conexión o devuelve una señal que permite intentarlo más tarde. Puede tener sentido reintentar, siempre que la operación sea segura al repetirse y exista un límite.
Fallo definitivo
La entrada es inválida, falta permiso, la credencial ya no es válida o una regla de negocio rechaza el caso. Repetir lo mismo sin cambiar nada no corrige la causa. Debe detenerse, registrar el motivo y dirigir el caso a la acción adecuada.
Resultado desconocido
Es el caso más engañoso: el destino pudo procesar la petición, pero la respuesta se perdió. El origen no sabe si debe repetir. Sin un identificador estable o una consulta de estado, el segundo intento puede duplicar el efecto.
La documentación del patrón Retry de Azure distingue la política según la naturaleza del fallo y los requisitos del proceso. También advierte que una operación no idempotente puede ejecutarse más de una vez si la respuesta se pierde (Microsoft Learn, observada el 29/08/2026). Es una condición de diseño, no una receta universal de intentos o tiempos.
El contrato mínimo de fiabilidad
Antes de configurar reintentos, completa esta tabla para cada efecto relevante.
| Campo | Pregunta |
|---|---|
| Evento | ¿Qué hecho inicia esta operación? |
| Identificador | ¿Qué valor estable reconoce una repetición del mismo hecho? |
| Efecto | ¿Qué cambio no debe aplicarse dos veces? |
| Estado | ¿Dónde consta recibido, en proceso, completado, fallido o dudoso? |
| Error | ¿Cómo se distingue un fallo temporal de uno que exige corrección? |
| Retry | ¿Qué condición permite repetir y qué límite lo detiene? |
| Reconciliación | ¿Cómo se compara origen, destino y efecto final? |
| Owner | ¿Quién resuelve la cola cuando el sistema no puede decidir? |
Una política global de «tres intentos para todo» evita tomar estas decisiones. El límite depende del efecto, la validez temporal de la operación, las señales del destino y la consecuencia de esperar o repetir.
Idempotencia: repetir la petición sin repetir el efecto
Una operación idempotente produce el mismo estado final cuando se solicita otra vez con la misma identidad. Eso no significa ignorar cualquier duplicado. Significa que el sistema reconoce que el efecto ya se aplicó o continúa la misma operación en lugar de crear otra.
Un patrón práctico contiene:
- una clave estable asociada al evento o a la intención;
- un registro que reserva o conserva esa clave;
- el estado y resultado de la operación;
- una respuesta coherente cuando llega de nuevo;
- una regla de caducidad compatible con el proceso.
El patrón Asynchronous Request-Reply de Azure muestra un ejemplo: el cliente aporta una idempotency key y, si llega duplicada, el sistema devuelve el recurso de estado existente en vez de encolar otro trabajo. También contempla error persistido, cancelación y compensación (Microsoft Learn, observada el 29/08/2026). Es un ejemplo de arquitectura; un flujo pequeño puede resolverlo de otra forma si conserva identidad, estado y efecto.
Diseña el reintento con salida, no como un bucle
Una política de retry necesita responder:
- qué errores son reintentables;
- qué operación puede repetirse de forma segura;
- cuánto esperar según la señal del servicio;
- qué límite de intentos o tiempo se aplica;
- qué ocurre al agotarlo;
- qué estado y contexto se conservan;
- quién recibe el caso.
Reintentar de inmediato y sin límite puede agravar una indisponibilidad. Azure denomina retry storm al patrón en que nuevas peticiones dificultan la recuperación del servicio y recomienda límites, espera creciente y respetar señales como retry-after (Microsoft Learn, observada el 29/08/2026). El valor concreto debe salir del servicio y del proceso, no de copiar una cifra.
Cuando el límite se alcanza, el flujo debe terminar en un estado explícito. «Falló» es insuficiente si no distingue pendiente de reconciliación, descartado por entrada inválida o detenido a la espera de una persona.
Reconciliar es comprobar el resultado, no ejecutar otra vez
La reconciliación compara lo que debía ocurrir con lo que consta en cada sistema. Puede ser necesaria cuando:
- el origen registró el envío, pero no tiene respuesta;
- el destino creó el objeto y el origen no guardó su identificador;
- dos sistemas muestran estados incompatibles;
- una ejecución parcial aplicó algunos efectos y otros no;
- el equipo corrigió manualmente un caso durante el incidente.
Define una consulta o informe que permita comparar:
| Elemento | Origen | Destino | Decisión |
|---|---|---|---|
| identificador | evento recibido | clave o registro asociado | ¿es la misma operación? |
| estado | enviado/en proceso/fallido | creado/actualizado/rechazado | ¿coinciden? |
| efecto | cambio esperado | cambio observado | ¿falta, sobra o está duplicado? |
| tiempo | inicio y último intento | creación/actualización | ¿sigue dentro del contexto válido? |
| resolución | pendiente | estado real | cerrar, compensar o revisar |
Reconciliar no siempre implica borrar el duplicado o repetir lo ausente. Puede exigir confirmar con una persona, conservar evidencia o aplicar una acción compensatoria. La matriz de excepciones antes de automatizar ayuda a decidir qué caso continúa, se detiene o necesita revisión.
Ejemplo ilustrativo: alta de una conversación en CRM
Imagina que una integración recibe un evento de conversación y debe actualizar el contacto, crear una oportunidad si corresponde y abrir una tarea para el responsable.
- Llega el evento
evt-123. - El sistema reserva esa identidad y marca la operación
en proceso. - Actualiza el contacto.
- Crea la oportunidad.
- La creación de la tarea termina, pero la respuesta se pierde.
- El proveedor reenvía
evt-123.
Si la segunda ejecución empieza desde cero, puede duplicar oportunidad y tarea. Si reconoce el evento y conserva los identificadores de los efectos completados, consulta el estado dudoso y solo resuelve lo pendiente.
Este ejemplo no prueba que un CRM o proveedor concreto funcione así. La guía de integración entre WhatsApp y CRM mantiene la aplicación específica a mensajería, identidad y seguimiento. Aquí el método sirve para cualquier integración con efectos repetibles.
Prueba tres fallos antes de dar el flujo por fiable
No necesitas provocar un incidente real. Prepara tres casos controlados:
- el destino devuelve un error temporal antes de procesar;
- procesa la operación, pero el origen no recibe respuesta;
- rechaza la entrada de forma definitiva.
Para cada uno, comprueba el estado final, los intentos registrados, la ausencia de efectos adicionales, la cola de revisión y la posibilidad de reconciliar. Si solo puedes saber el resultado mirando manualmente varias herramientas sin identificador común, el flujo todavía no tiene un contrato observable.
La comparación entre n8n y Make para empresas ayuda a evaluar herramientas; no sustituye estas decisiones. La herramienta ejecuta la política que se diseñe, con sus propios límites.
Checklist de idempotencia, retry y reconciliación
- Cada efecto relevante tiene una unidad y un identificador estable.
- El estado distingue recibido, en proceso, completado, fallido y dudoso.
- Los fallos temporales y definitivos siguen rutas distintas.
- Solo se reintentan operaciones seguras al repetirse.
- La política tiene espera, límite y salida explícita.
- El destino y sus señales cambian la política cuando corresponde.
- El agotamiento crea una cola con owner y contexto.
- Existe una comparación entre evento, estado y efecto final.
- Las correcciones manuales quedan registradas.
- Los casos no resolubles automáticamente pueden detenerse.
Después del lanzamiento, estas decisiones necesitan owner, alertas y runbook. La guía para operar una automatización después del lanzamiento continúa ese trabajo sin convertir V2 en una sola pieza genérica.