La demo siempre funciona. El problema aparece un martes a las 3:00, cuando la API del CRM devuelve un error 500, el flujo se detiene a mitad de un pedido y nadie se entera hasta que el cliente pregunta. La diferencia entre un flujo de juguete y uno de producción no está en los nodos: está en lo que pasa cuando algo falla.
Diseña asumiendo que todo falla
- Reintentos con espera creciente: la mayoría de errores de API son pasajeros; reintentar a los 30 segundos resuelve lo que a la primera falló.
- Rutas de error explícitas: cada paso crítico tiene definido qué pasa si sale mal, aunque sea solo «avisa y para».
- Idempotencia: si el flujo se ejecuta dos veces con el mismo pedido, no puede crear dos pedidos. Se comprueba antes de escribir, siempre.
- Pasos atómicos: mejor tres flujos pequeños encadenados que uno de cuarenta nodos imposible de reanudar a mitad.
Si falla, que avise antes de que lo note tu cliente
Todo flujo en producción envía sus errores a un canal que alguien mira —Slack, correo— con el contexto necesario para actuar: qué falló, con qué datos, y enlace a la ejecución. El histórico de ejecuciones se conserva para poder reconstruir cualquier incidencia. «Se rompió hace tres días y no nos dimos cuenta» es el fallo de diseño más caro que existe.
Los puntos de control humanos no son opcionales
Reembolsos, cambios de dirección, respuestas a clientes enfadados: lo que tiene coste de error alto pasa por una persona, no porque la máquina no pueda, sino porque el día que se equivoque saldrá más caro que todo lo ahorrado. Definir qué decide la máquina y qué decide una persona es parte del diseño, no un parche posterior.
Mide la fiabilidad, no la sensación
Dos números bastan para saber si una automatización es de fiar: el porcentaje de ejecuciones correctas (en producción sana, por encima del 99 %) y el tiempo que pasa entre que algo falla y alguien lo sabe (minutos, no días). Si tu plataforma no te deja medir ambos, ese es el primer problema que resolver.