«El flujo funciona bien en pruebas, pero en producción falla a veces sin motivo aparente.» Si alguna vez has escuchado (o dicho) esta frase, es muy probable que el motivo sea throttling: el flujo está pidiendo más de lo que el conector o la licencia permiten en un periodo de tiempo. No es un fallo aleatorio, es un límite documentado que se está tocando.
Qué son los límites de solicitudes y el throttling
Según la documentación oficial de Power Platform, cada acción de un flujo —tanto si tiene éxito como si falla— cuenta como una «solicitud» (request), y esas solicitudes están sujetas a límites que dependen del tipo de licencia asignada al flujo o a su propietario. Cuando se supera ese límite, o el límite propio de un conector concreto, la plataforma responde con un error HTTP 429 (Too Many Requests), típicamente indicando cuántos segundos hay que esperar antes de reintentar.
Es importante distinguir dos capas de límites: los límites de la plataforma (basados en la licencia, por ejemplo un número de solicitudes por cada 24 horas) y los límites propios de cada conector (por ejemplo, cuántas llamadas por minuto admite un servicio concreto antes de devolver un 429). Un flujo puede ir sobrado en la primera capa y aun así toparse con la segunda.
Cómo afecta la concurrencia en «Apply to each»
Un bucle Apply to each puede ejecutar sus iteraciones en paralelo, y eso se controla con la opción de concurrencia (degree of parallelism). Por defecto, las iteraciones se ejecutan de una en una; se puede aumentar ese grado de paralelismo hasta un máximo definido por la plataforma para acelerar el procesamiento de listas grandes.
Aquí está la trampa: si dentro del bucle hay una llamada a un conector con un límite de solicitudes por minuto ajustado, subir la concurrencia puede disparar el número de llamadas simultáneas contra ese conector y provocar throttling justo en el peor momento, con un lote grande de elementos a procesar.
Buenas prácticas para evitar el throttling
La documentación de Microsoft recomienda varias prácticas que, combinadas, reducen mucho el riesgo:
- Paginación: recuperar los datos en páginas o lotes en lugar de traer todo de golpe, para no disparar un pico de solicitudes en una sola acción.
- Procesamiento por lotes (batching): agrupar operaciones en llamadas de lote cuando el conector lo admite, en lugar de una llamada por cada elemento.
- Condiciones de desencadenador: filtrar en el propio disparador para que el flujo no se ejecute más veces de las necesarias.
- Ajustar la concurrencia del «Apply to each»: no siempre más paralelismo es mejor; hay que calibrarlo según los límites del conector implicado.
- Dividir en flujos hijos: repartir la carga entre varios flujos en lugar de concentrar todas las solicitudes en uno solo.
| Situación | Riesgo | Mitigación |
|---|---|---|
| Apply to each con 5.000 elementos | Throttling del conector por llamadas simultáneas | Reducir concurrencia y/o procesar por lotes |
| Flujo disparado por cada correo entrante | Ejecuciones innecesarias que consumen solicitudes | Condición de desencadenador para filtrar antes de arrancar |
| Consulta a una API externa sin paginar | Respuestas muy grandes y llamadas repetidas | Paginación explícita en la propia llamada |
La retry policy (política de reintento) de una acción define cuántas veces y con qué intervalo se reintenta automáticamente una llamada fallida antes de darla por definitivamente fallida. Es la primera línea de defensa ante un throttling puntual: un 429 aislado a menudo se resuelve solo con un reintento algo más espaciado, sin que el flujo entero se caiga.
Para terminar
El throttling no es un bug de Power Automate, es un mecanismo de protección para que un flujo pesado no deje sin servicio a un conector compartido por todo el tenant. Diseñar teniendo en cuenta límites, concurrencia y reintentos desde el principio evita muchos sustos el día que el volumen de datos deja de ser el de pruebas (veinte registros) y pasa a ser el real (veinte mil).
Y cuando aun así aparece un 429, lo peor que se puede hacer es ignorarlo o reintentar manualmente sin más: conviene revisar en el historial de ejecuciones qué acción concreta lo generó, comprobar si su política de reintento está activa y, si el patrón se repite, replantear la concurrencia o el volumen de la llamada que lo provoca.
¿Y qué pasa cuando ese throttling provoca un fallo justo en medio de un flujo, en lugar de limitarse a ralentizarlo?
Leer el artículo sobre manejo de errores, run after y scopes