Un flujo de aprobación parece el caso fácil: alguien pide, alguien aprueba, se avisa. Es el que más pedidos pierde. No por la herramienta, sino por cuatro decisiones de diseño que parecen inofensivas el primer día.
Error uno: marcar el registro antes de que el aviso salga
El patrón es tentador. Marcas el elemento como «avisado» y después envías el correo, porque así el flujo no puede duplicar el aviso si se reintenta.
El problema es lo que pasa cuando el envío falla. El registro ya dice «avisado», el filtro de pendientes ya no lo muestra, y ese pedido sale del radar para siempre.
Nadie lo reclama porque nadie sabe que existe.
Cómo se arregla: marcar después de la confirmación de envío, y tener un estado intermedio —«en curso»— para el hueco entre las dos acciones. Si el flujo muere en medio, el elemento se queda visible en un filtro de revisión en lugar de desaparecer.
Error dos: un correo por línea de pedido
Cuando el flujo recorre las líneas de un pedido y envía dentro del bucle, un pedido de seis líneas genera seis correos. El aprobador recibe seis avisos casi idénticos, deja de leerlos al tercero, y a partir de ahí el circuito está roto aunque técnicamente funcione.
Cómo se arregla: recoger las líneas primero, componer una sola tarjeta con cabecera y contador, y enviar una vez por pedido. La regla práctica: un aviso por decisión humana, no por fila de base de datos.
Error tres: aprobar sin contexto suficiente
Las aprobaciones se responden desde el móvil, entre dos cosas. Si el aviso solo dice «Pedido 2026-418 pendiente de aprobación», el aprobador tiene que entrar a buscar qué es, y eso convierte una respuesta de diez segundos en una tarea pendiente para la tarde. La tarde no llega.
Cómo se arregla: meter en el propio aviso lo mínimo para decidir —quién pide, qué, cuánto, para cuándo y por qué— y dejar el enlace para el que quiera profundizar. Si la decisión se puede tomar sin abrir nada, se toma.
Error cuatro: que toda la cadena dependa de una cuenta personal
Este es el más caro y el más común. El flujo se creó con la cuenta de alguien, las conexiones son suyas y los permisos cuelgan de su usuario. Funciona perfectamente hasta el día en que esa persona se va de vacaciones, cambia de departamento o deja la empresa.
Entonces se cae todo a la vez y nadie sabe por dónde empezar.
Cómo se arregla: cuenta de servicio o solución propietaria del flujo, permisos por grupo y no por persona, y documentar el identificador real de cada elemento —no su nombre, que se repite— para que el que llegue después sepa qué está mirando.
Lo que hay que poder responder
Antes de dar por bueno un circuito de aprobación, conviene poder contestar estas cuatro:
- Si el aviso falla, ¿dónde aparece ese pedido mañana?
- ¿Cuántos correos recibe el aprobador por pedido?
- ¿Se puede decidir sin abrir otra pantalla?
- Si la persona que lo montó no está, ¿sigue funcionando?
Si alguna no tiene respuesta, ahí está el pedido que se va a perder.
Escribí cómo se rompe un flujo por una acción olvidada en otro artículo. Si tienes un circuito de aprobación que ya está perdiendo cosas, cuéntamelo o mira cómo lo abordo.