Los errores de un escenario de Make necesitan clasificación, límites de reintento y un responsable de recuperación. Guardar ejecuciones incompletas no está activado por defecto. Diseña y prueba el comportamiento ante fallos antes de confiar al escenario acciones como crear pedidos, enviar mensajes o actualizar estados comerciales.
APLICABILIDAD
¿Dónde importa esta decisión?
- Empresas de servicios
- Equipos de marketing y operaciones
Distingue fallos recuperables de datos que necesitan corrección
Una conexión temporalmente caída puede justificar reintentar; un dato obligatorio ausente necesita revisión. Un permiso revocado requiere corregir acceso, no repetir indefinidamente. Establece categorías y respuestas concretas para cada integración. La etiqueta genérica “error” no permite decidir si conviene esperar, corregir un registro o detener un proceso.
Antes de configurar manejadores, identifica qué módulos producen efectos externos y cuáles solo leen información. Un fallo al final del escenario puede ocurrir después de haber creado un contacto o enviado una notificación. Reejecutar desde el principio sin verificar esos efectos puede duplicarlos. La recuperación debe respetar el estado confirmado de cada sistema.
Configura almacenamiento y recuperación conscientemente
Make permite guardar ejecuciones incompletas, pero esa opción debe habilitarse en la configuración del escenario. Comprueba su funcionamiento en un entorno controlado y revisa condiciones y capacidad de tu plan. El historial y los datos retenidos también requieren una política de acceso y conservación; no almacenes información sensible por tiempo indefinido sin necesidad.
La documentación describe reintentos automáticos para determinados errores y configuraciones del manejador Retry. No extrapoles ese comportamiento a cualquier fallo. Define límites, espera y un destino de revisión cuando no se complete la operación. Una alerta debe llegar a alguien con capacidad para resolver y explicar qué acciones ya ocurrieron antes del error.
Ensaya el fallo más costoso antes de activar
Ejemplo de prueba: interrumpe una respuesta del CRM después de que el contacto se haya creado. Verifica si puedes recuperar el escenario conservando un único contacto y una única tarea. Repite con un dato inválido para comprobar que no se trate como un fallo temporal. Identifica los registros de prueba y evita utilizar clientes reales para estos ensayos.
Conserva evidencia de la prueba, versión del escenario y procedimiento de recuperación. Después de modificar módulos o credenciales, repite casos críticos. El indicador operativo debe incluir ejecuciones pendientes de atención, no solo porcentaje de éxito. Un sistema puede parecer estable mientras acumula excepciones que nadie revisa y contactos que nunca reciben seguimiento.
ENTIDADES ANALIZADAS
FUENTES
Referencias utilizadas.
- Ejecuciones incompletasMake Help Center
- Reintento automático de ejecuciones incompletasMake Help Center
PREGUNTAS FRECUENTES
Respuestas breves para decidir.
¿Make guarda siempre los procesos fallidos?
No debes asumirlo. La opción de guardar ejecuciones incompletas está desactivada por defecto y debe configurarse. Verifica además qué información se conserva y cómo se recupera.
¿Conviene reintentar todos los errores?
No. Separa fallos temporales de datos inválidos, permisos y reglas de negocio. Los reintentos deben tener límites y no repetir efectos ya confirmados.
¿Cómo compruebo que el escenario es recuperable?
Simula interrupciones y datos inválidos en un entorno controlado. La recuperación debe completar el resultado sin duplicar escrituras o mensajes y dejar evidencia para el responsable.