Flujos que envejecen bien: buenas prácticas en Power Automate

La mayoría de los flujos de trabajo surgen como una solución rápida y efectiva a problemas concretos y específicos. Estos flujos operan adecuadamente, aportando un valor significativo y logrando replicarse exitosamente en diversas circunstancias. Sin embargo, surge un desafío considerable cuando se pasa de manejar tres flujos en operación a gestionar un total sorprendente de trescientos, al pasar de contar con un único creador a la gestión de múltiples equipos involucrados, y de un uso ocasional a que dichos flujos se conviertan en un proceso crítico de negocio esencial para el funcionamiento cotidiano de la organización.

En este crucial punto de transición, muchos entornos de Power Automate comienzan a presentar síntomas preocupantes e indeseables:

• Flujos que se vuelven lentos, lo que impacta negativamente en la eficiencia operativa.
• Errores que resultan difíciles de diagnosticar, provocando frustración entre los usuarios.
• Cambios inesperados que afectan el rendimiento sin intervención directa, lo que puede generar confusión y desasosiego entre los usuarios.
• La falta de claridad en la función de cada flujo dentro de la organización, lo que complicará tanto su gestión como su mantenimiento.

Este artículo no tiene como objetivo afirmar que “Power Automate es deficiente”, sino más bien abordar el por qué su rendimiento puede deteriorarse con el tiempo y qué patrones conducen directamente a la inmantenibilidad de los flujos en uso.

En los siguientes puntos vamos  intentar abordar buenas practicas.

BUCLES

El síntoma

El patrón suele empezar de forma inocente y aparentemente sin complicaciones.

Tienes un flujo que trabaja eficientemente con Dataverse y, de repente, una acción devuelve varios registros:
una lista de productos, contactos relacionados, tareas hijas, líneas de pedido… en múltiples formatos y con diferentes atributos.

La reacción automática es casi siempre la misma entre los desarrolladores y usuarios:

“Vale, esto es un array… Apply to each.” La solución parece simple y directa.

Funciona. Todo bien, hasta que comienzan a surgir otras consideraciones.

Pero dentro de ese bucle aparece otro array:

• productos con descuentos
• registros relacionados
• resultados de otra consulta a Dataverse

Y vuelves a pensar:

“Bueno, pues otro Apply to each.”

Y dentro de ese segundo bucle… aparece un tercero etc....

Por qué se convierte en una deuda técnica

• Rendimiento impredecible
• Depuración difícil
• Complejidad explosiva

Caso típico en Dataverse (muy común)

“Cuando una Oportunidad se marca como Ganada, actualiza sus Productos y crea Facturas por línea”.

Estructura típica (mal):

• Trigger: Opportunity updated
• Get related products
• Apply to each product
  • Create invoice line
  • Update product status
• Update opportunity

Funciona con 3 productos. Sin embargo, sufres enormemente con 300 productos en total.

Cómo arreglarlo

1.- Reduce el volumen antes de iterar, usa un filtro para quedarte con lo que importa.

2.- Recomiendo maximo un bucle por rama

3.- paralelizar cuando sea Posible => en las propiedes del Apply for each puedes activar Concurrency Control para acelerar…
PERO: solo si cada iteración es independiente.

caso de uso donde aplicarlo: crear registros que no chocan entre sí.
caso de uso donde no aplicarlo: actualizar el mismo registro desde varias iteraciones.

NOMENCLATURAS

Si tu flujo tiene acciones llamadas “Condition 1”, “Compose 4” o “Initialize variable 2”, mantenerlo va a ser complicado… incluso para ti mismo. No hoy, pero sí dentro de dos semanas, cuando vuelvas a él para hacer un pequeño cambio y ya no recuerdes por qué existe cada cosa.

Este es uno de los problemas más comunes en Power Automate y también uno de los más fáciles de evitar. No tiene que ver con la lógica, ni con Dataverse, ni con el rendimiento. Tiene que ver con algo mucho más básico: la legibilidad.

Un flujo no se mantiene mientras lo construyes, se mantiene cuando alguien (o tú mismo) lo lee tiempo después. Y ahí es donde los nombres genéricos pasan factura.

Una naming convention mínima que lo cambia todo

No necesitas normas complejas ni un documento de 20 páginas. Con una nomenclatura muy sencilla, tus flujos se vuelven mucho más claros.

Para las acciones, una regla que funciona muy bien es:
Verbo + Objeto + Detalle.

Por ejemplo:

• Get Opportunity
• List Opportunity Products
• Validate Data – Mandatory fields
• Update Opportunity – Set status Won

Solo con esto, alguien que abra el flujo puede seguir la historia sin entrar en cada acción. El flujo empieza a leerse casi como un texto.

Los scopes también necesitan hablar claro

Los scopes suelen llamarse simplemente “Scope” o, con suerte, “Try”. Eso no aporta contexto. El scope no es solo un contenedor técnico, es una parte del proceso.

Una convención muy fácil y muy efectiva es usar scopes con intención clara:

• TRY – Main process para el flujo principal
• CATCH – Error handling para la gestión de errores
• FINALLY – Telemetry para cierre, logs y métricas

Cuando ves estos nombres, no necesitas pensar. Sabes exactamente qué esperar dentro de cada bloque.

MANEJO DE ERRORES

Tu flujo falla. Power Automate lo marca en rojo. Y ahí se queda.
Esta es una situación sorprendentemente habitual y, a la vez, una de las más peligrosas cuando trabajas con procesos reales. El error existe, pero nadie lo ve, nadie lo entiende y nadie actúa hasta que el negocio empieza a notar que “algo no funciona”. En ese momento, ya vas tarde.

En automatización real, el objetivo no es que un flujo no falle nunca. Eso es irreal. El objetivo es que, cuando falle, lo haga de forma controlada y útil. Un buen flujo debe permitirte saber qué ha fallado, con qué datos y, si es posible, volver a procesarlo sin tener que reconstruir nada a mano. Dicho de otra forma: no se trata de evitar el error, sino de diseñar para el error.

Una forma muy sencilla y muy efectiva de conseguirlo es aplicar el patrón TRY / CATCH / FINALLY, usando scopes. En el scope TRY – Main process colocas toda la lógica principal del flujo: lecturas de Dataverse, validaciones, creaciones y actualizaciones de registros. Es el “happy path”, el escenario en el que todo funciona como esperas.

El scope CATCH – Log & notify se ejecuta solo si algo falla. Para ello, se configura el Run after para que se active cuando el TRY haya fallado, se haya omitido o haya hecho timeout. Dentro de este bloque no se intenta “arreglar” el proceso a la fuerza, sino que se gestiona el error de forma consciente: se registra el fallo en Dataverse con la información relevante, se notifica al canal de soporte (por ejemplo, en Teams) y, si el proceso lo permite, se puede incluso crear una tarea o dejar el caso preparado para reprocesarlo más adelante.

Por último, el scope FINALLY – Telemetry se ejecuta siempre, independientemente de si el flujo ha ido bien o mal. Este bloque sirve para cerrar el proceso de forma limpia: registrar la duración de la ejecución, guardar el estado final y asociar todo al mismo correlationId. Gracias a esto, puedes tener trazabilidad completa del flujo y entender qué ocurrió sin necesidad de abrir cada ejecución una por una.

Cuando aplicas este patrón, el flujo deja de ser una caja negra. Los errores ya no son eventos misteriosos marcados en rojo, sino información útil que te permite actuar rápido, con datos y sin miedo.

ESCALABILIDAD

Hablar de escalabilidad en Power Automate no significa pensar solo en volumen o rendimiento, sino en la capacidad de una automatización para seguir siendo comprensible, fiable y mantenible a lo largo del tiempo. Un flujo escalable es aquel que puede crecer en uso, en complejidad o en número de personas implicadas sin volverse frágil ni generar miedo a modificarlo. Esto implica asumir desde el diseño que el flujo cambiará, que fallará en algún momento y que no siempre lo mantendrá la misma persona que lo creó. La escalabilidad, por tanto, no es una característica técnica aislada, sino una combinación de buenas decisiones de estructura, claridad, manejo de errores y trazabilidad que permiten que la automatización evolucione junto al negocio sin convertirse en una carga.

Patrones PRO

Algunos patrones que suelen considerarse “pro” pueden aplicarse perfectamente desde un enfoque maker si se entienden bien. Un buen ejemplo es el patrón de cola en Dataverse, muy útil cuando el trigger de un flujo puede dispararse muchas veces o en picos altos: en lugar de procesar todo “en caliente”, el flujo simplemente escribe un registro en una tabla tipo Queue y otro flujo, normalmente programado, se encarga de procesar esos elementos poco a poco. Esto permite controlar mejor la carga, simplificar los reintentos y tener una auditoría natural de todo lo que ha pasado.

Otro patrón clave es la idempotencia, que consiste en evitar duplicados cuando un flujo se re‑ejecuta: para ello basta con definir una clave única (por ejemplo, OpportunityId + tipo de proceso) y comprobar antes de crear nada si ya existe un registro relacionado. Para un maker, algo tan sencillo como una acción de List rows con un filtro antes de crear una invoice puede marcar la diferencia entre un flujo robusto y uno que genera problemas difíciles de corregir.

CONCLUSIONES