Power Automate: Search for users (V2) y filtro por Account Enabled en Microsoft 365

¿Tu flujo no trae todos los usuarios de Microsoft 365 cuando usas la acción Search for users (V2)? En esta guía aprenderás por qué ocurre, cómo habilitar la paginación para superar el límite visible de 1.000, y cómo filtrar por cuentas activas (accountEnabled = true) sin sobrecargar tu entorno.

Índice

Contexto y objetivo

Un escenario común en Power Automate es recorrer usuarios de Microsoft 365 para crear elementos en una lista de SharePoint (por ejemplo, un directorio interno). Sin embargo, muchos flujos se quedan cortos porque la acción Search for users (V2) no devuelve la lista completa a la primera. ¿La razón? Un límite de elementos por ejecución y la ausencia de un parámetro directo para filtrar por Account Enabled. Aquí verás cómo solucionarlo de forma fiable, escalable y mantenible.

Resumen clave

Límite por defecto: sin ajustar la configuración, la acción puede devolver como máximo 1.000 usuarios por llamada visible en el flujo.
Paginación: habilítala en Settings de la acción y define un Threshold adecuado (por ejemplo, 10.000) para traerlo todo en varias páginas.
Filtro por Account Enabled: la acción no expone este filtro. Aplica el filtrado en el flujo (Filter array) o consulta Microsoft Graph con $filter=accountEnabled eq true.
Optimización: usa Search term para acotar el conjunto de resultados y Top para controlar el tamaño de página (no filtra, solo limita).

Qué está pasando con el límite

Muchas acciones «de listado» en Power Automate devuelven un máximo de resultados por ejecución si no activas la paginación. Con Search for users (V2) esto se traduce en un corte alrededor de los 1.000 usuarios visibles, por lo que un tenant con más usuarios parecerá «incompleto». La paginación se encarga de realizar fetch de páginas sucesivas hasta alcanzar el Threshold que especifiques (por ejemplo, 10.000).

Cómo habilitar la paginación paso a paso

En tu flujo, localiza la acción Search for users (V2) del conector Office 365 Users.
Abre el menú de la acción (⋯ > Settings).
Activa Pagination y establece Threshold = 10000 (o el número que necesites en tu escenario).
Guarda y vuelve a ejecutar el flujo. Ahora la acción recorrerá páginas sucesivas (según el tamaño de página interno) hasta alcanzar el umbral.

Buenas prácticas al paginar

Configura un Threshold alineado con el volumen real de usuarios. Evita umbrales arbitrariamente altos en entornos pequeños.
Si el volumen es muy grande, evalúa filtrar en origen con Graph para reducir los datos transferidos.
Monitorea la duración del flujo. Paginaciones amplias implican más rondas de red.

Reducir resultados desde la propia acción

Aunque Search for users (V2) no permite filtrar por accountEnabled, sí ofrece dos controles que ayudan:

Search term: acota por nombre, UPN, correo, etc. Esto sí reduce el conjunto devuelto.
Top: controla cuántos elementos trae por página. No filtra; solo limita la cantidad por llamada.

Parámetro	Qué hace	Para qué usarlo	Limitaciones
Search term	Devuelve usuarios relevantes según la cadena de búsqueda.	Acotar por nombre, UPN o correo y evitar traer «todo».	No permite expresiones complejas ni filtrar por `accountEnabled`.
Top	Limita el tamaño de página.	Controlar carga por petición y tiempos de respuesta.	No es un filtro; necesitas paginación para «el resto».

Filtrar por cuentas habilitadas

La acción Search for users (V2) no expone un parámetro para Account Enabled = true. Para lograrlo, tienes dos rutas prácticas:

Opción A: filtrar dentro del flujo

Recupera usuarios con paginación y usa un Filter array para quedarte con los que tengan accountEnabled en true.

Agrega Filter array tras la acción de búsqueda.
En la condición, usa una expresión similar a:
@equals(item()?['accountEnabled'], true)
Envía la salida filtrada a tu Apply to each y crea los elementos en SharePoint con esa lista reducida.

Importante: según el conector y el perfil devuelto, puede que accountEnabled no venga en la respuesta de Search for users (V2). Si no aparece:

Recupera el detalle de cada usuario con una acción que sí devuelva accountEnabled (por ejemplo, Azure AD > Get user o Graph).
Filtra después de enriquecer los datos, o bien cambia a la Opción B para filtrar en origen.

Opción B: filtrar del lado del servidor con Microsoft Graph

Para máxima eficiencia en tenants grandes, llama a Microsoft Graph con $filter=accountEnabled eq true desde una acción HTTP o un conector adecuado. Traerás solo usuarios activos, reduciendo tráfico y tiempo.

Ejemplo con HTTP (con Azure AD/Entra ID):

Method: GET
URI: https://graph.microsoft.com/v1.0/users
     ?$select=id,displayName,userPrincipalName,accountEnabled
     &$filter=accountEnabled eq true
     &$top=999
Headers:
  Authorization: (se gestiona por el conector)
  Accept: application/json

Notas:

Usa paginación con @odata.nextLink si hay más de 999 resultados.
Permisos sugeridos (delegados o de aplicación según tu modelo): User.Read.All o Directory.Read.All. Consulta con tu equipo de seguridad qué alcance corresponde a tu caso.
Si también necesitas invitados o distinguir tipos, añade $filter=userType eq 'Member' o 'Guest' según corresponda.

Implementación de extremo a extremo

El siguiente patrón crea elementos en SharePoint solo para usuarios activos:

Detonador: manual, programado o HTTP (según tu escenario).
Ruta A (rápida):
Office 365 Users > Search for users (V2) con paginación habilitada. Luego Filter array por accountEnabled y Apply to each para crear en SharePoint.
Si accountEnabled no viene en la salida, inserta un paso intermedio: Azure AD > Get user para enriquecer.
Ruta B (eficiente en grandes volúmenes):
HTTP a Graph con $filter=accountEnabled eq true, paginar con @odata.nextLink, y Apply to each directo a SharePoint.
Creación en SharePoint: SharePoint > Create item mapeando campos:
- Title ⇢ displayName
- UPN ⇢ userPrincipalName
- Cuenta habilitada ⇢ accountEnabled
- Id de usuario ⇢ id

Control de duplicados

Si ejecutas el flujo de forma recurrente, evita duplicados con uno de estos enfoques:

Clave única: añade una columna «UPN» con índice en SharePoint y usa un Get items previo con Filter Query (por ejemplo, UPN eq '@{items('Applytoeach')?['userPrincipalName']}'). Crea el elemento solo si no existe.
Actualizar o crear: si existe, usa Update item; si no, Create item.

Rendimiento y estabilidad

Paginación consciente: establece Threshold ajustado a la realidad. Evitar «100.000 por si acaso» reduce riesgos de tiempo de ejecución y límites.
Top razonable: usa Top para páginas más pequeñas si notas latencia o cortes intermitentes.
Paralelismo responsable: en Apply to each, habilita Concurrency Control (p.ej. 10) cuando tengas llamadas independientes. Úsalo con prudencia para no provocar limitaciones del servicio.
Selección de campos: con Graph, usa $select para traer solo lo que necesites.
Reintentos y control de errores: ajusta Retry policy para acciones HTTP; encapsula pasos en Scope con ramas de éxito y fallo.

Tabla comparativa de enfoques

Enfoque	Ventajas	Desventajas	Cuándo usar
Search for users con paginación + Filter array	Configuración rápida, sin llamadas HTTP adicionales.	Transferencia de más datos si hay muchos usuarios; puede requerir enriquecimiento para `accountEnabled`.	Tenants medianos o pequeños; prototipos y flujos simples.
Graph con `$filter=accountEnabled eq true`	Menos datos, mayor eficiencia y control; filtrado en origen.	Requiere permisos adecuados y montar paginación con `@odata.nextLink`.	Tenants grandes, flujos con ejecución programada o críticos en tiempo.

Errores frecuentes y solución

La lista se corta en 1.000: faltó habilitar Pagination o el Threshold es demasiado bajo.
No aparece accountEnabled en la salida: la acción no devuelve ese campo; añade un paso de detalle (Azure AD) o cambia a Graph.
Demasiado lento: reduce Top, limita campos con $select y activa paralelismo con prudencia.
Throttling 429 en Graph: implementa reintentos y espaciado; baja la concurrencia.
Duplicados en SharePoint: añade índice/clave y comprueba existencia antes de crear.

Patrón de paginación con Graph

Cuando uses Graph, la clave está en leer @odata.nextLink mientras exista:

Inicializa una variable Url con la primera URI (la del ejemplo con $filter y $select).
Do until que Url sea vacía:
- HTTP GET a Url.
- Añade los value recibidos a una array variable.
- Actualiza Url = body('HTTP')?['@odata.nextLink'] (o vacía si no existe).
Usa la array final como entrada al Apply to each y crea en SharePoint.

Expresiones útiles

Filtrar usuarios activos en Filter array:
@equals(item()?['accountEnabled'], true)
Comprobar que viene UPN:
@and(not(empty(item()?['userPrincipalName'])), item()?['accountEnabled'])
Generar etiqueta segura para SharePoint:
@coalesce(item()?['displayName'], item()?['userPrincipalName'])

Checklist de implementación

Paginación activada en Search for users (V2) con Threshold suficiente.
Uso de Search term y Top para acotar y controlar el tamaño de página.
Filtrado por accountEnabled mediante Filter array o Graph con $filter.
Mapeo de campos a SharePoint y control de duplicados.
Paralelismo y reintentos configurados con criterio.
Registros de diagnóstico (variables/compose) para trazabilidad.

Preguntas frecuentes

¿Hay un límite de resultados en Search for users (V2)?
Sí. Si no habilitas paginación, verás un máximo de 1.000 usuarios por ejecución. Con paginación, puedes incrementar el umbral (por ejemplo, 10.000) para traer todo lo necesario.

¿Puedo filtrar directamente por Account Enabled en esa acción?
No. La acción no expone ese filtro. Filtra en el flujo con Filter array o consulta Graph con $filter=accountEnabled eq true.

¿El parámetro Top filtra resultados?
No. Top solo define cuántos elementos trae por página. Para recortar realmente el conjunto, usa Search term o filtra en origen con Graph.

¿Qué permisos requiere Graph para leer accountEnabled?
Depende de tu modelo (delegado o aplicación). A nivel general, User.Read.All o Directory.Read.All cubren el escenario de listar usuarios y leer accountEnabled. Valídalo con tu administrador.

¿Cómo manejo invitados frente a internos?
Usa $filter=userType eq 'Member' o 'Guest' en la consulta de Graph, o filtra después en el flujo.

Plantilla rápida

Detonador
  ↓
Search for users (V2)
  Settings: Pagination = On, Threshold = 10000
  Inputs: Search term (opcional), Top (opcional)
  ↓
[Opcional] Para cada usuario: Azure AD &gt; Get user (si necesitas accountEnabled)
  ↓
Filter array
  Condition: @equals(item()?['accountEnabled'], true)
  ↓
Apply to each (usuarios activos)
  SharePoint &gt; Create item
  - Title = displayName
  - UPN = userPrincipalName
  - Enabled = accountEnabled

Conclusión

El problema no es la acción en sí, sino la configuración por defecto y la ausencia de un filtro explícito por Account Enabled. Al habilitar la paginación y elegir conscientemente dónde filtrar (en el flujo o en el origen con Graph), obtendrás un proceso robusto y escalable. Para pocos cientos de usuarios, la combinación Search for users (V2) + Filter array suele ser suficiente. En tenants grandes, el camino eficiente es Graph con $filter, seleccionando solo los campos necesarios y aplicando paginación de forma controlada.

Buenas prácticas rápidas

Si esperas más de 1.000 usuarios, activa paginación desde el principio.
Usa Search term para acotar y Top para controlar tamaño de página.
Si solo necesitas usuarios activos, valora ir directo a Graph con $filter=accountEnabled eq true.
Implementa control de duplicados y registra métricas de ejecución para depurar.