El rediseño iba bien. Había cambiado la forma en que un flujo de aprobación construye su correo: en lugar de una tabla HTML generada automáticamente —esas tablas grises que nadie lee—, cada pedido pasaba a ser una tarjeta con su cabecera, su contador de líneas y el formato de la casa.
Para hacerlo, la acción Seleccionar pasó de modo tabla a modo texto, generando directamente el HTML de cada tarjeta. Eso dejaba sin trabajo a la vieja acción Crear tabla HTML. Y aquí tomé la decisión que me costó la mañana: no la borré. La dejé ahí, huérfana, con el razonamiento de que si había que revertir el cambio, tenerla en su sitio abarataba la vuelta atrás.
Lo que pasó
La ejecución de las 13:09 recogió seis pedidos reales y se cortó con este error:
The property 'columns' must be specified unless the 'from' property
value is an array of objects.
Crear tabla HTML seguía ejecutándose. Con Seleccionar en modo texto, su entrada ya no era una colección de objetos, así que falló. Y como la acción Redactar que venía después tenía un runAfter sobre ella, la cadena entera se detuvo ahí.
Resultado: seis pedidos reales sin correo de aviso.
La parte fea
El daño no fue solo el correo que no salió. Ese flujo, por un problema de diseño anterior a mi cambio, marca los pedidos como «Esperando Aprobación» antes de construir y enviar el correo. Así que los seis pedidos quedaron marcados como avisados, sin que se hubiera avisado a nadie, y fuera del filtro de «Pendiente» para siempre.
Un fallo de mi cambio se convirtió en pérdida de información gracias a una fragilidad que ya estaba ahí.
Ese es el patrón que más veces he visto: el error nuevo no rompe nada por sí solo, lo que rompe es cómo se apoya en algo que ya estaba mal.
Las tres lecciones
Una acción huérfana no es una acción inocua. En Power Automate, cada acción se ejecuta salvo que su runAfter diga lo contrario, y el runAfter de las que vienen después puede seguir apuntando a ella. Desactivarla no es lo mismo que sacarla del grafo: mientras alguien dependa de ella, forma parte de la cadena.
«Por si acaso» no es un plan de reversión. Un plan de reversión es el contenido literal de los campos que vas a tocar, guardado fuera de la herramienta, y las instrucciones para volver a pegarlo. Dejar restos dentro del flujo no es cautela, es dejar una trampa.
Marca el estado al final, no al principio. Si el proceso escribe «ya avisado» antes de enviar el aviso, cualquier fallo posterior se convierte en pérdida silenciosa.
El orden correcto es: enviar, comprobar y solo entonces marcar.
Qué cambió desde entonces
Ahora trabajo así: cada paso de una edición larga se guarda por separado, con nota de versión, para poder decir exactamente en cuál se rompió algo; el contenido original de cada campo que toco se copia fuera antes de tocarlo; y las acciones que dejan de tener sentido se borran en el mismo cambio en que dejan de tenerlo, reconectando los runAfter que las apuntaban.
Los seis pedidos se restauraron uno a uno con sus unidades originales, rescatadas del historial de versiones de cada elemento. Costó una mañana. El arreglo de fondo —mover la marca de estado a después del envío— entró en el plan como lo que era: no un extra, sino la causa real de que un fallo de diez minutos costara media jornada.