Gestión de errores en la automatización de flujos de trabajo: cómo los procesos siguen siendo fiables incluso ante fallos

La alarma no la da un sistema, sino una clienta. Hizo una consulta hace una semana a través del formulario de contacto y nunca recibió respuesta. En el CRM no aparece. Según el registro, el formulario envió una confirmación, y el flujo de trabajo muestra marcas verdes. En algún punto intermedio algo se perdió, y no hay rastro de ello.

En este escenario, una empresa de servicios con dos docenas de empleados mantiene cuatro automatizaciones: consultas de formulario al CRM, facturas del buzón a la contabilidad, recordatorios de citas por correo electrónico y un informe semanal. Cada una se construyó por separado y funcionó satisfactoriamente durante meses. Nadie definió nunca qué debía ocurrir si un paso fallaba.

Es el caso normal, no la excepción. Al construir un flujo de trabajo se piensa en el camino que funciona. Pero el día a día también consiste en caminos que no funcionan: un servicio que no responde durante una hora, un campo obligatorio que llega vacío, un límite diario que se alcanza a las 15 horas. Quien no diseña estos casos los diseña igualmente, solo que sin querer y casi siempre como pérdida de datos.

Lo peligroso no es tanto la caída total como la caída parcial. Si una automatización falla por completo, normalmente se nota en un día, porque falta algo habitual. Pero si solo pierde uno de cada veinte casos, cualquier muestra parece buena. El daño se reparte a lo largo de semanas, se atribuye a personas concretas y no aparece como causa en ninguna estadística. Precisamente esta clase de error convierte una automatización cómoda en un riesgo en el que se confía a ciegas.

El primer tipo es la interfaz caída. Un servicio responde con un error de servidor, agota el tiempo de espera o sencillamente no es accesible. La causa queda fuera de su influencia y suele ser pasajera. Aquí ayuda la paciencia en forma de reintentos controlados y, si no basta, un aplazamiento limpio con aviso.

El segundo tipo son los datos incompletos o inverosímiles: una dirección de correo sin arroba, un importe como texto, un campo obligatorio que un formulario dejó pasar. Reintentar no tiene sentido, porque el mismo registro fallará una y otra vez. Esto corresponde a una persona que decida si se corrige, se pregunta o se descarta.

En tercer lugar, límites y cuotas. Casi toda interfaz limita las llamadas por minuto o por día y responde a un exceso con un aviso, casi siempre con el estado 429, a menudo con una indicación de cuánto hay que esperar. Es un error que exige consideración, no insistencia. En cuarto lugar, duplicados: los webhooks se entregan a veces más de una vez, los usuarios hacen clic dos veces, un reintento se topa con un paso que en realidad ya se había completado.

La distinción es el núcleo del asunto. Quien trata los cuatro casos con el mismo mecanismo, por ejemplo «ante un error, reintentar tres veces», causa daño: martillea un servicio limitado, repite datos sin remedio defectuosos y, con los duplicados, genera todavía más.

No todo error merece el mismo cuidado. Un informe semanal que no llega es molesto, una consulta de cliente perdida es cara, una factura enviada dos veces es embarazosa y, según el caso, jurídicamente desagradable. Por eso el primer análisis no pregunta qué puede salir mal técnicamente, sino cuál sería el peor resultado realista en cada paso.

Para ello recorremos los flujos de trabajo paso a paso y anotamos tres cosas por paso: ¿qué ocurre si falla? ¿Qué ocurre si se ejecuta dos veces? ¿Y quién lo notaría, y cuándo? La tercera pregunta es la más incómoda, porque a menudo la respuesta es «probablemente la clienta, dentro de una semana». Precisamente esos pasos tienen prioridad.

A ello se suma la dependencia de sistemas ajenos. Una interfaz que usted no controla cambiará tarde o temprano: se renombra un campo, se retira una versión, se sustituye un método de autenticación. No es cuestión de si ocurrirá. Por eso el análisis recoge qué pasos dependen de qué servicios externos y con qué rapidez se notaría un cambio.

De las respuestas surge una matriz sencilla de daño y riesgo de detección. Los pasos con mucho daño y poca visibilidad reciben el tratamiento completo con clave, cola y alarma. Los pasos con poco daño y mucha visibilidad, como un informe que no llega y se echa de menos enseguida, se conforman con un reintento sencillo y un aviso. Así el esfuerzo se mantiene proporcionado y los procesos, comprensibles.

El principio que subyace a todas las medidas es: un error nunca debe quedar invisible, y nada debe perderse antes de que una persona lo haya visto o lo haya descartado a propósito. De ahí se deriva un orden de medios. Primero el sistema intenta ayudarse a sí mismo, por ejemplo con un reintento. Si no lo logra, deposita el caso en un lugar seguro. Solo entonces avisa, y de forma dirigida.

Una alternativa sería avisar de cada error de inmediato. Suena meticuloso y a las dos semanas acaba en un buzón que nadie lee. Los avisos sobre cosas que se curan solas generan fatiga, y el único aviso importante se pierde entre ellos. Por eso apostamos por umbrales: una única solicitud reintentada es material de registro; un servicio que lleva diez minutos sin responder merece una llamada.

Una segunda alternativa es un enfoque de todo o nada, en el que un flujo de trabajo se interrumpe por completo ante cada error y se revierte. Eso encaja con las transacciones de bases de datos, pocas veces con procesos que tocan varios sistemas ajenos: un correo enviado no se puede recuperar. Es más práctico diseñar los pasos de modo que puedan ejecutarse de nuevo con seguridad y continuar el caso en el punto en que se detuvo.

Concebimos la gestión de errores en capas que actúan de dentro hacia fuera. En el interior está el paso individual con su comprobación de los datos de entrada. A su alrededor, la lógica de reintentos; después, el resguardo en una cola; y en el exterior, la observación con avisos. Cada capa recoge lo que la interior no pudo resolver y lo transmite con más contexto.

Es importante la comprobación en la entrada. Antes de que un paso se dirija a un sistema ajeno, se comprueban los campos obligatorios, los formatos y la verosimilitud: ¿la dirección está bien formada?, ¿el importe está dentro de lo esperable?, ¿la fecha no está en el pasado? Así, los datos no válidos ni siquiera entran en un ciclo de reintentos, sino que van directamente adonde una persona los revisa.

Forma parte del diseño decidir también quién es responsable de qué. Una cola de revisión sin una persona designada es un cementerio. Por eso fijamos quién la abre cada día, cuánto tiempo puede permanecer un registro y qué ocurre si se supera ese plazo. En equipos pequeños suele bastar una persona con una sustitución clara; lo decisivo es el compromiso.

Un ejemplo de cómo encaja todo: el formulario entrega una consulta con un número de teléfono no válido. La comprobación de entrada la clasifica como dudosa, la deposita en la cola junto con el texto original y avisa a la persona responsable. El contacto ni se descarta ni se da de alta sin revisar. Pocos minutos después, una persona corrige el número, confirma, y el proceso continúa donde se había detenido.

En los reintentos da buen resultado un intervalo creciente llamado backoff exponencial: por ejemplo, tras uno, luego cuatro, luego dieciséis segundos, con un límite máximo de intentos y de tiempo de espera. A ello se añade una pequeña dispersión aleatoria para que diez casos fallidos no vuelvan exactamente al mismo tiempo y vuelvan a sobrecargar el servicio recién recuperado. Solo se reintenta ante agotamiento de tiempo, errores de servidor y limitación, no ante errores que la propia llamada ha causado, como entradas no válidas.

Si una interfaz indica durante la limitación cuánto hay que esperar, el flujo de trabajo sigue esa indicación en lugar de hacer su propio cálculo. Ante una presión de límite persistente, conviene agrupar las llamadas o repartirlas en el tiempo. Un límite diario no se supera reintentando; exige una decisión: aplazar hasta la siguiente ventana de tiempo o ajustar el plan con el proveedor.

Idempotencia significa que un paso, ejecutado varias veces, da el mismo resultado que ejecutado una sola vez. Técnicamente se logra con una clave por caso, por ejemplo el ID del formulario o un identificador formado por remitente, asunto y fecha. Antes de crear algo, el paso comprueba si esa clave ya se procesó. Algunas interfaces admiten estas claves directamente; en otras llevamos una pequeña tabla propia de casos completados.

La clave debe elegirse estable y, al mismo tiempo, adecuada. Si es demasiado burda, dos consultas auténticas de la misma persona el mismo día cuentan como duplicado. Si es demasiado fina, por ejemplo con una marca de tiempo en la clave, el duplicado nunca se reconoce. No hay una solución general, solo la pregunta de qué constituye lo mismo en cada caso.

El caso especial más delicado es el caso a medio completar. Un flujo de trabajo crea un contacto en el CRM, envía una confirmación y falla en el tercer paso, la creación de una tarea. Un reinicio desde el principio genera un segundo contacto y un segundo correo. Por eso el proceso recuerda, para cada caso, qué pasos están hechos y continúa en el primero que sigue abierto. Este seguimiento del estado supone un esfuerzo adicional, pero evita justamente las duplicidades que más problemas causan después.

Un segundo caso especial: el error solo aparece a veces. Una interfaz responde en el dos por ciento de los casos con un campo vacío que de otro modo nunca está vacío. Los mensajes de error aislados dicen poco al respecto; un registro con contexto sí: qué caso, qué paso, qué entrada, qué respuesta. Ahí se ve el patrón, por ejemplo que siempre afecta a registros con diéresis o tildes en un campo determinado.

En tercer lugar, el cambio paulatino en las interfaces ajenas. Un proveedor añade un campo, cambia un formato o desactiva una versión antigua. En el peor de los casos el flujo de trabajo sigue funcionando y entrega resultados erróneos sin que nadie lo note, por ejemplo porque un importe llega ahora en céntimos en lugar de en euros. Ayudan las comprobaciones de verosimilitud sobre los resultados, las pruebas funcionales con un registro de prueba y la lectura de las notas de cambios del proveedor, que programamos como una cita fija.

En cuarto lugar, afecta a las personas que corrigen los errores. Una cola de revisión solo funciona si cada registro contiene todo lo necesario para decidir: los datos originales, el motivo del error en palabras comprensibles y un botón o instrucciones para la siguiente acción. Si alguien tiene que buscar primero en tres sistemas, la cola se evita.

Cabe esperar no tanto una reducción de los errores como un cambio en sus consecuencias. Los errores siguen produciéndose, porque los sistemas ajenos siguen siendo propensos a fallos. La diferencia: ya no provocan consultas perdidas ni asientos duplicados, sino un registro en la cola y un aviso. El beneficio está en que los fallos pierden su coste, no en que desaparezcan.

Esto puede medirse con pocos indicadores. El tiempo entre la aparición y la detección de un error debería bajar de días a minutos u horas. El porcentaje de casos resueltos automáticamente, es decir, errores solucionados por sí solos mediante reintento, muestra cuánto trabajo quita el sistema. La antigüedad del registro más viejo de la cola de revisión revela si alguien se ocupa de ella. A ello se suman las quejas o preguntas de clientes que apuntan a pérdidas.

También es realista una fase de arranque. En las primeras semanas, la observación muestra patrones de error que antes nunca eran visibles, y el número de avisos sube al principio. Eso es un éxito de la visibilidad, no un retroceso. Después se ajustan los umbrales y se eliminan las causas frecuentes. No garantizamos tasas concretas, porque dependen de los sistemas ajenos, de la calidad de los datos y de la disciplina del equipo.

Quien quiera saber más con precisión, observa los errores por causa en lugar de por cantidad. Si se acumulan los agotamientos de tiempo en un solo servicio, merece la pena hablar con el proveedor o cambiar. Si se acumulan los errores de datos en un punto de entrada, la solución está en el formulario, no en el flujo de trabajo. Así la observación conduce no solo a una reacción más rápida, sino, a largo plazo, a menos fallos en el origen.

El primer principio: la gestión de errores pertenece al diseño, no al final. Quien la añade después debe rehacer flujos de datos que ya funcionan en producción. Por eso, en los flujos de trabajo nuevos planteamos la pregunta sobre el fallo antes que la pregunta sobre la función. Eso cuesta una tarde en el diseño y ahorra semanas más tarde.

El segundo: los registros necesitan estructura y reglas de conservación. Un registro debería contener el ID del caso, el paso, el momento, el resultado y el motivo del error, pero ningún dato personal innecesario en texto plano. Cuánto tiempo se guardan los registros es también una cuestión de protección de datos que conviene aclarar con su asesoría de protección de datos. Lo mencionamos aquí como indicación, no como información jurídica.

El tercero: los flujos de trabajo son software y merecen control de versiones y pruebas. Cada cambio se lleva como una versión nueva, con una breve nota sobre qué cambió y por qué, y puede revertirse. Un pequeño conjunto de casos de prueba que cubra el caso normal, una caída del servicio, un duplicado y un registro roto se ejecuta tras cada cambio. Es menos esfuerzo de lo que parece y detecta los errores derivados más frecuentes.

El cuarto se refiere a las propias alarmas. Un aviso vale lo que vale su contenido: nombra el flujo de trabajo, el paso, el caso, el motivo y un enlace al lugar donde se puede actuar. Y llega a una persona o a un canal que se lee, no a una dirección colectiva. De noche no tiene que sonar todo, pero para las consultas de clientes y los flujos de pago debería estar claro quién mira primero por la mañana.

El quinto se refiere al calendario. Las automatizaciones nuevas deberían pasar por una fase de observación más estrecha antes de dejarlas solas. Y después hacen falta fechas fijas de mantenimiento, porque incluso un flujo de trabajo tranquilo se queda anticuado.

La automatización fiable no se demuestra en el funcionamiento normal, sino el día en que algo no cuadra. Entonces se decide si un caso permanece resguardado, avisado y trazable o desaparece sin dejar rastro. La gestión de errores es la parte del trabajo que no se ve después cuando está bien hecha, y que se echa muy claramente en falta cuando no está.

El siguiente paso es pequeño. Elija uno de sus flujos de trabajo y recórralo paso a paso: ¿qué ocurre si este paso falla? ¿Y si se ejecuta dos veces? ¿Quién lo notaría? Si alguna de las preguntas no tiene una respuesta clara, ha encontrado la primera laguna. Con gusto revisamos con usted dos o tres procesos y le decimos con claridad dónde hay mayor necesidad de actuar y dónde basta ya con una simple alarma.

Lo realista es avanzar paso a paso. No tiene que reorganizar todos los procesos a la vez. Empiece por aquel en el que perder un caso sale más caro y después traslade los patrones a los demás. Ya una comprobación de entrada, una clave contra duplicados y una alerta fiable cambian notablemente la situación, aunque la fase completa de desarrollo aún esté pendiente.

Hay un límite que conviene tener presente: ninguna gestión de errores hace más fiables los sistemas de terceros; solo hace que sus procesos resistan mejor sus debilidades. Y no sustituye a una persona que abra realmente la cola. La técnica y la responsabilidad van juntas.