Optimización del rendimiento para flujos de Power Automate

Un flujo de Power Automate que tarda varios minutos en una tarea que en realidad podría completarse en segundos no solo cuesta tiempo. Consume innecesariamente muchas de las solicitudes de acciones limitadas de tu plan, provoca más errores de tiempo de espera en los sistemas posteriores y dificulta la resolución de problemas, porque cada ejecución debe recorrer más pasos. La buena noticia: la mayoría de los problemas de rendimiento en Power Automate se pueden reducir a tres palancas, que Microsoft documenta en detalle en sus propias directrices de codificación. Actualizado: julio de 2026.

Este artículo resume cómo puedes crear flujos notablemente más rápidos mediante un paralelismo dirigido, la reducción de acciones innecesarias y la elección correcta de conector y de datos, basándote en la documentación oficial de Microsoft sobre Power Automate. Así mantienes el control sobre qué palanca tiene el mayor efecto en tu flujo concreto, en lugar de tocar ajustes al azar que apenas cambian algo.

Por qué los flujos se vuelven lentos

Antes de optimizar, vale la pena mirar la causa. Según la guía sobre Diagnóstico de problemas de rendimiento, muchos flujos ralentizados simplemente alcanzan sus límites diarios de Power Automate. El análisis de acciones en «Mis flujos» te muestra cuántas solicitudes de acciones consume realmente un flujo, y Power Automate incluso notifica a los propietarios por correo electrónico cuando un flujo supera repetidamente los límites de acciones. Igual de importante: los propios servicios conectados también aplican límites de protección, que se muestran en tu flujo como error 429 (demasiadas solicitudes) o 5xx (tiempo de espera agotado). Estos límites varían según el conector y el servicio, por lo que la misma lógica de flujo puede rendir de forma muy distinta en SharePoint que en Dataverse o en una API externa.

Palanca 1: usar el paralelismo de forma dirigida

Ramas paralelas para pasos independientes

Según la guía sobre la ejecución paralela y el paralelismo, las ramas paralelas merecen la pena siempre que dos o más acciones no dependan entre sí y cada una tarde más de cinco segundos. Según Microsoft, los casos de uso típicos son las solicitudes de aprobación no bloqueantes, los procesos de aprobación basados en quórum, la creación o actualización simultánea de registros en varios sistemas y la inicialización en paralelo de varias variables.

Control de simultaneidad en los bucles Aplicar a cada uno

El efecto es aún más claro en los bucles. De forma predeterminada, un bucle Aplicar a cada uno funciona de manera secuencial, elemento por elemento. La documentación muestra, con una matriz de prueba de cuatro entradas, cuánto se acorta esto gracias al paralelismo:

• Paralelismo desactivado: 21 segundos
• Grado de paralelismo 2: 11 segundos
• Grado de paralelismo 4: 6 segundos
• Grado de paralelismo 6: 6 segundos

Puedes establecer el grado de paralelismo entre 1 y 50. Importante: un número alto no acelera automáticamente todo, porque dividir el trabajo, encolar hilos adicionales y los retrasos causados por el propio endpoint invocado generan una sobrecarga propia. Además, los bucles Aplicar a cada uno anidados siempre se ejecutan de forma secuencial; según Microsoft, el control de paralelismo solo actúa en el nivel superior del flujo en la nube.

Paralelismo del desencadenador: solo con precaución

A nivel del desencadenador, además puedes activar un control de simultaneidad, que determina cuántas instancias de un flujo pueden ejecutarse al mismo tiempo; está desactivado de forma predeterminada. Ayuda con fuentes de datos de rendimiento limitado y evita las llamadas lecturas sucias (dirty reads), en las que un flujo sigue trabajando con datos obsoletos porque una ejecución paralela modificó el registro mientras tanto. Sin embargo, Microsoft recomienda explícitamente actuar con precaución: una vez activado, este ajuste ya no se puede desactivar, solo recreando el desencadenador. Como práctica recomendada, la documentación aconseja aplicar el control de simultaneidad únicamente a un flujo secundario dedicado con el menor número de acciones posible, en lugar de afectar a todo el flujo principal.

Palanca 2: reducir acciones y bucles innecesarios

Evitar bucles anidados

La guía sobre antipatrones en flujos en la nube menciona los bucles Aplicar a cada uno anidados como una de las trampas más costosas. Dos bucles con diez iteraciones cada uno dan como resultado matemático 100 ejecuciones; con volúmenes de datos mayores, esta cifra crece de forma exponencial y alcanza rápidamente los límites de iteraciones y de tiempo total de ejecución. La alternativa documentada: usar la expansión de consultas OData para cargar registros relacionados en una sola consulta, en lugar de recuperarlos en un segundo bucle interno. Un parámetro como `Products($select=ProductName,Price)` sustituye así todo el bucle interno por una única llamada adicional RetrieveMultiple a Dataverse.

Condiciones de desencadenador en lugar de comprobaciones posteriores

Muchos flujos se inician con cada cambio en una fuente de datos, aunque solo una fracción de las ejecuciones sea realmente relevante. Una condición de desencadenador, comprobada directamente en el propio desencadenador, evita estas ejecuciones superfluas desde el principio, en lugar de detectarlas solo después de iniciarse el flujo mediante una condición interna. Esto ahorra no solo tiempo, sino también las solicitudes de acciones que de otro modo se consumirían en cada ejecución irrelevante.

Operaciones por lotes y masivas en lugar de acciones individuales

Según la documentación, quien necesite crear o actualizar cientos o miles de registros no debería procesar cada registro individualmente en un bucle For each. Las operaciones por lotes agrupan varias solicitudes en una única solicitud HTTP, mientras que las API web de operaciones masivas de Dataverse van un paso más allá: en lugar de muchas acciones individuales de «Crear fila», una sola llamada a la API web CreateMultiple con 100 registros preparados cuenta como una única acción.

Palanca 3: elección de conector y limitación del volumen de datos

Cargar solo los datos que realmente necesitas

Según la guía Trabajar solo con datos relevantes, el volumen de datos procesado se puede limitar tanto en el desencadenador como en acciones individuales. En fuentes de Dataverse, los parámetros Seleccionar columnas, Filtrar filas y Número de filas reducen el conjunto de resultados directamente en el origen. En SharePoint, Consulta de filtro, Número máximo y Limitar columnas según la vista cumplen el mismo propósito. Esto es relevante porque los llamados límites de rendimiento (throughput limits) determinan cuánto volumen de datos puede leer y escribir un flujo en la nube desde su historial de ejecución dentro de un período de tiempo. Si este límite se supera de forma continua durante 14 días, Power Automate desactiva automáticamente el flujo.

La acción correcta en lugar de la más cómoda

Elegir el conector adecuado también significa no recurrir automáticamente a la acción más costosa para la misma tarea. Operaciones de datos como Filter array, Select o Join procesan matrices directamente y reducen el volumen de datos que pasa por los pasos siguientes, a menudo de forma mucho más eficiente que un bucle adicional con condiciones. Cuando un servicio ofrece parámetros nativos de filtrado o selección directamente en el propio conector, según la documentación de Microsoft es más eficiente filtrar ahí en lugar de cargar primero todo el volumen de datos en el flujo y reducirlo después con una operación de datos independiente.

Cómo encontrar el cuello de botella en tu propio flujo

La forma más rápida de encontrar la causa real es con un orden de comprobación fijo. Abre primero el análisis de acciones del flujo afectado y comprueba si está cerca de sus límites diarios. Después revisa el historial de ejecución en busca de acciones individuales con una duración llamativamente larga; normalmente son bucles sin paralelismo o acciones que cargan volúmenes de datos innecesariamente grandes. Comprueba también si aparecen errores del tipo 429 o 5xx, que indican límites de un servicio conectado y no de Power Automate en sí. Para entornos de flujos más amplios con varios entornos, suele merecer la pena una consultoría de Power Automate estructurada que revise sistemáticamente el paralelismo, el volumen de datos y la elección de conectores para todos los flujos críticos a la vez, en lugar de optimizar cada flujo por separado.

Preguntas frecuentes

¿Cuántos elementos debería procesar en paralelo en un bucle Aplicar a cada uno?

No existe un valor óptimo universal; Microsoft permite un grado de paralelismo entre 1 y 50. En la medición de ejemplo documentada con cuatro elementos, un paralelismo de 4 ya proporcionaba la aceleración máxima, y aumentarlo a 6 no cambiaba nada más en el tiempo de ejecución. En la práctica, conviene empezar con un valor moderado, entre 5 y 10, y observar el tiempo de ejecución en el historial, en lugar de establecer directamente el valor máximo, porque un paralelismo demasiado alto puede generar por sí mismo retrasos causados por el endpoint invocado.

¿El control de simultaneidad del desencadenador mejora automáticamente el rendimiento?

No de forma automática, y Microsoft incluso recomienda moderación. La configuración predeterminada sin control de simultaneidad permite tantas ejecuciones simultáneas como el sistema pueda procesar, lo cual ya es suficientemente eficiente para la mayoría de los escenarios. El control de simultaneidad tiene sentido sobre todo cuando un recurso conectado solo admite un rendimiento limitado o cuando hay que evitar lecturas sucias (dirty reads), no como medida general de aceleración. Como este ajuste no se puede revertir, deberías aplicarlo solo de forma puntual a un flujo pequeño y dedicado.

¿Por qué son los bucles anidados un problema de rendimiento tan grande?

Porque el número de ejecuciones se multiplica en lugar de sumarse. Dos bucles anidados entre sí, con diez elementos cada uno, dan como resultado 100 ejecuciones individuales; con volúmenes de datos mayores, esta cifra sigue creciendo de forma exponencial. Esto no solo cuesta tiempo, sino que además acerca rápidamente el flujo a los límites de iteraciones y de tiempo total de ejecución, lo que en el peor de los casos provoca errores de flujo o limitación de velocidad (throttling).

¿Qué tiene que ver la elección del conector con el rendimiento cuando varios conectores pueden realizar la misma tarea?

Los conectores suelen ofrecer parámetros de filtrado y selección con distintos niveles de granularidad directamente en la fuente de datos. Un conector que ya admite filtrado, selección de columnas y un número máximo de filas en el desencadenador o en la acción reduce el volumen de datos procesado antes incluso de que llegue al flujo. Esto repercute directamente en los límites de rendimiento y reduce el riesgo de que un flujo se vea limitado por un volumen de datos demasiado alto, o incluso desactivado automáticamente tras una superación prolongada.

¿Cómo saber si un flujo lento se debe a Power Automate o al servicio conectado?

Un vistazo a los códigos de error en el historial de ejecución da la respuesta. Los errores de tipo 429 o los tiempos de espera agotados en el rango 5xx indican límites de protección del servicio conectado, que varían según el conector. Si, en cambio, Power Automate alcanza sus propias solicitudes de acciones diarias, el análisis de acciones en «Mis flujos» lo muestra claramente, y los propietarios reciben además una notificación automática con consejos para reducir el número de acciones.