Una automatización que deja de funcionar puede dejar consultas sin respuesta, datos desactualizados o tareas bloqueadas sin que nadie lo note. Por eso no basta con comprobar que el flujo se haya iniciado: también hay que saber qué ocurre cuando falla un paso.
Conviene definir tres aspectos: cómo detectar el error, quién debe intervenir y cómo reanudar el trabajo sin repetir acciones que ya se hayan completado.
Por qué una automatización puede detenerse sin que sea evidente
Un flujo depende de herramientas, conexiones y datos que pueden cambiar. Una contraseña puede caducar, un servicio externo puede tardar demasiado, faltar un campo obligatorio o una API puede rechazar una solicitud temporalmente. A veces la plataforma registra una ejecución fallida, pero el aviso se queda dentro del sistema y nadie lo revisa.
El riesgo aumenta cuando el proceso recibe una consulta, crea un contacto en el CRM, envía una confirmación o actualiza un pedido. En esos casos, que la automatización no avise también es un problema operativo, aunque la web siga funcionando.
1. Decide qué errores deben generar un aviso
No todas las incidencias necesitan la misma respuesta. Como mínimo, distingue entre:
- error temporal: un tiempo de espera agotado o un servicio que no está disponible por un momento;
- dato no válido: falta un campo o el formato no es el esperado;
- error de configuración: credenciales caducadas, permisos insuficientes o un endpoint que ha cambiado;
- resultado incierto: puede que la solicitud se haya procesado, pero la automatización no recibió confirmación.
Este último caso requiere especial atención: repetir la acción enseguida puede crear un contacto, envío u operación duplicados. El aviso debe incluir el paso afectado, el momento y una referencia a la ejecución, sin exponer datos personales innecesarios.
2. Envía el aviso a una persona responsable
Un mensaje genérico a una dirección que nadie revisa no resuelve nada. Cada flujo importante necesita una persona responsable y un canal de aviso comprobado. Si el proceso es crítico, define también quién puede sustituirla.
En n8n, por ejemplo, se puede asociar un flujo de errores a la configuración de otro workflow para que se ejecute cuando falla una ejecución. El nodo Error Trigger recibe detalles del error y puede activar un aviso por correo o Slack. Las opciones concretas dependen de la configuración y la versión; comprueba el comportamiento con una ejecución de prueba.
3. Registra qué ha ocurrido
Un registro útil permite saber si el problema es puntual o recurrente. Para cada error, conserva al menos:
- nombre del flujo y paso que se detuvo;
- fecha y hora;
- identificador de la consulta o elemento afectado;
- mensaje técnico esencial y reintentos realizados;
- resultado de la intervención y persona que lo resolvió.
No hace falta recopilarlo todo. Limita los datos personales, establece durante cuánto tiempo conservar los registros y asegúrate de que las personas autorizadas sepan dónde consultarlos.
4. Reintenta solo cuando sea seguro
Un nuevo intento puede tener sentido ante un error temporal. Antes, comprueba si la acción anterior llegó a completarse. Por ejemplo: ¿el CRM creó el contacto aunque la respuesta del servicio tardara demasiado? ¿Se envió el correo antes del timeout? Sin esa comprobación, el reintento puede duplicar el resultado.
Cuando sea posible, utiliza un identificador único de la solicitud y comprueba si ya existe antes de crear otra. Si no puedes confirmar el resultado, deja el elemento en una cola para revisarlo manualmente en lugar de repetir la acción a ciegas.
5. Prueba también el recorrido de error
Una automatización no está lista solo porque funcione en el caso ideal. Simula al menos un error temporal, un dato ausente y unas credenciales no válidas. Comprueba que llega el aviso, que el registro se entiende y que la persona responsable sabe cómo reanudar el proceso.
Repite estas comprobaciones después de cambiar campos, integraciones, permisos o herramientas. Una prueba breve y documentada suele ser más útil que un procedimiento largo que nadie sigue.
Lista de comprobación antes de automatizar un proceso
- ¿Qué resultado concreto debe producir?
- ¿Qué errores pueden detenerlo?
- ¿Quién recibe el aviso y quién puede sustituirle?
- ¿Cómo se comprueba si la acción ya se ha realizado?
- ¿Qué datos se registran y durante cuánto tiempo?
- ¿Cómo se reanuda el flujo sin crear duplicados?
En el método de Digital Noa, la primera pregunta no es «¿qué integración conectamos?», sino «¿dónde se interrumpe el trabajo y quién se entera?». Imagina un formulario de contacto: si el CRM crea el lead pero la confirmación agota el tiempo de espera, antes de reintentar comprobamos si el contacto ya existe. Es un ejemplo práctico, no el relato de un caso de cliente. Primero aclaramos el proceso, las responsabilidades y el riesgo de duplicados; después elegimos las herramientas. Puedes ampliar la información en nuestro artículo IA y WordPress: qué merece realmente la pena automatizar.
