por Hola a todos:
Cuando diseñamos un flujo en Power Automate, solemos empezar pensando en registros:
Tengo 500 elementos.
Tengo 6.000 registros.
Tengo una lista de SharePoint que necesito actualizar.
Tengo una tabla de Excel que debo recorrer.Pero el consumo real de un flujo no depende solo del número de registros. Depende de lo que ocurre dentro de cada vuelta del bucle.
Ahí aparecen tres conceptos que conviene separar bien:
Iteraciones
Acciones
Llamadas al conectorUna iteración es cada vuelta de un bucle, por ejemplo cada vuelta de un Aplicar a cada uno.
Una acción es cada paso que se ejecuta en el flujo: filtrar una matriz, evaluar una condición, crear un elemento, actualizar un registro, enviar un correo, etc.
Una llamada al conector es una acción que contacta con un servicio externo, por ejemplo SharePoint, Dataverse, Excel Online, Outlook, Teams o SQL.
Imaginemos un flujo que procesa 6.000 registros. Si dentro del bucle ejecutamos cuatro pasos:
1. Filtrar matriz
2. Evaluar una condición
3. Actualizar elemento
4. Crear elemento relacionadopodríamos decir que tenemos:
6.000 registros = 6.000 iteracionesPero realmente estamos ejecutando:
6.000 iteraciones × 4 acciones = 24.000 accionesY si dos de esas acciones llaman a SharePoint, entonces tendremos además:
6.000 registros × 2 llamadas SharePoint = 12.000 llamadas al conectorPor eso, cuando un flujo empieza a crecer, no basta con mirar cuántos registros procesa. Hay que mirar cuántas acciones se ejecutan dentro de cada vuelta y cuántas de ellas llaman realmente a un conector.
Microsoft indica que las solicitudes de Power Platform incluyen acciones de conectores, acciones HTTP, acciones integradas, reintentos y paginación, entre otras; además, cuentan tanto acciones correctas como fallidas.
En este caso voy a centrar el ejemplo en SharePoint, porque es uno de los escenarios más habituales: listas, bibliotecas, permisos, actualizaciones masivas, cargas desde Excel, procesos de aprobación, etc.
Pero la idea no es exclusiva de SharePoint. También aplica cuando trabajamos con:
Dataverse
Excel Online
Outlook
Teams
SQL
OneDrive
Conectores personalizadosLa diferencia es que cada conector tiene sus propias características y sus propios límites. Microsoft explica que, además de los límites generales de la plataforma, cada conector puede tener límites propios de throughput o throttling; cuando se superan, pueden aparecer errores como 429 Too Many Requests.
ada una de esas acciones puede suponer una llamada real al conector de SharePoint.
Y aquí hay dos límites distintos que debemos tener en cuenta.
Por un lado están las solicitudes generales de Power Platform, que dependen de la licencia o capacidad asignada. Microsoft indica que Power Automate Premium permite 40.000 solicitudes de Power Platform en 24 horas por usuario, mientras que una licencia Power Automate Process asignada a un flujo permite 250.000 solicitudes en 24 horas para ese flujo y sus flujos asociados.
Por otro lado están los límites propios del conector. Microsoft explica que los conectores tienen límites separados como mecanismo de protección. En el caso del conector de SharePoint, se cita un límite de 600 operaciones por minuto por conexión; si se supera, el flujo puede recibir errores 429.
Esto es muy importante: comprar más capacidad ayuda con el límite diario, pero no convierte SharePoint en ilimitado.
Si un flujo va a procesar miles de registros, ejecutar decenas de miles de acciones o formar parte de un proceso corporativo estable, tiene sentido valorar una licencia adecuada, como Power Automate Premium o Power Automate Process.
Pero comprar capacidad no arregla un mal diseño.
Si dentro de cada iteración hay demasiadas acciones, si el flujo no filtra desde origen, si procesa todo cada vez, si no guarda estado, o si lanza demasiadas llamadas concurrentes al mismo conector, aparecerán problemas igualmente.
Algunos síntomas habituales son:
Flujos muy lentos
Errores intermitentes
Reintentos continuos
Errores 429
Registros a medio procesar
Ejecuciones difíciles de auditar
Procesos que hay que relanzar desde ceroCuando el conector principal es SharePoint, suelo aplicar estas reglas:
Filtrar desde origen siempre que sea posible.
Usar columnas indexadas.
Procesar solo registros pendientes.
Evitar actualizar registros que no han cambiado.
Reducir acciones dentro del bucle.
No enviar correos si no son necesarios.
Evitar concurrencia alta en procesos sensibles.
Procesar por lotes si el volumen es grande.
Guardar estado de proceso.
Relanzar solo errores o pendientes.Un patrón muy útil es añadir campos de control a la lista:
ESTADO_PROCESO
FECHA_PROCESO
ERROR_PROCESOLo importante es distinguir:
Iteraciones: cuántas vueltas da el bucle.
Acciones: cuántos pasos se ejecutan.
Llamadas al conector: cuántas peticiones reales hacemos al servicio.
Límites de licencia: cuánta capacidad tenemos.
Límites del conector: cuánto aguanta el servicio conectado.Y ojo, También hay algo que conviene tener presente: no todos los problemas se resuelven añadiendo acciones a un flujo.
A veces escuchamos frases como: Esto se hace rápido. No le des tantas vueltas. No pierdas demasiado tiempo en el diseño. Luego ya lo ajustamos….
y finalmente, lloramos.
Un flujo mal diseñado puede funcionar en una prueba con 10 registros y fallar cuando se ejecuta con 6.000. Puede parecer correcto en una primera versión y empezar a dar problemas cuando aparecen errores intermitentes, registros duplicados, elementos sin actualizar o llamadas bloqueadas por el conector.
Os dejo una imagen con el esquema completo del artículo:
