Power Automate no es "IA": es el fontanero de Microsoft 365
Antes de decidir si Power Automate es tu herramienta conviene saber qué es de verdad, porque el nombre engaña. Power Automate es la pieza de automatización de la Power Platform de Microsoft: mueve datos entre tus aplicaciones, dispara avisos, lanza aprobaciones y ejecuta flujos cuando pasa algo. Nació como reglas fijas —si entra un correo con adjunto, guárdalo en SharePoint— y a eso se le ha ido pegando IA (Copilot para montar el flujo, AI Builder para leer un documento). Pero su ADN sigue siendo el de un motor de flujos determinista pegado a Office, no el de un sistema que decide con criterio. Confundir las dos cosas es el primer error caro.
Por eso esta guía no va de "cómo automatizar Microsoft 365" —esa es otra conversación, la de montar una capa de IA sobre tu suite, que tratamos en IA para Microsoft 365—. Va de una decisión anterior: cuándo Power Automate es la herramienta correcta para tu empresa y cuándo estás forzándola a hacer algo para lo que hay opciones mejores. Es el mismo ejercicio que elegir herramienta de automatización, aplicado al caso concreto de quien ya vive dentro de Microsoft.
Cuándo Power Automate es la respuesta obvia
Hay tres situaciones donde Power Automate gana casi sin discusión, y las tres tienen que ver con dónde vive ya tu empresa, no con lo lista que sea la herramienta. La primera: estás dentro de Microsoft 365 hasta el cuello. Si tu correo es Outlook, tus documentos viven en SharePoint y Teams, tu gente trabaja en Excel y tu identidad la gobierna Entra (el antiguo Azure AD), Power Automate habla ese idioma de forma nativa. No hay conector que mantener ni permiso que pelear: la herramienta ya está dentro de tu perímetro y tu administrador ya la controla.
La segunda: flujos de aprobación. Vacaciones, gastos, validación de una factura, un alta que necesita tres visto-buenos. Power Automate hace esto especialmente bien —tarjetas de aprobación en Teams y Outlook, con rastro de quién aprobó qué y cuándo— y es la razón por la que muchas empresas lo adoptan sin haber decidido nada más. La tercera: RPA sobre sistemas viejos que no tienen API. Si tienes un ERP de hace quince años o una aplicación de escritorio con la que hay que interactuar a golpe de clic, los desktop flows de Power Automate automatizan esa interacción como un robot que usa la pantalla. Ahí compite con UiPath y Automation Anywhere, no con Zapier.
El modelo de licencia que nadie mira hasta que llega la factura
Aquí es donde casi todo el mundo se lleva el susto. Power Automate viene "incluido" en muchos planes de Microsoft 365, y esa palabra —incluido— es la trampa. Lo que entra gratis son los flujos que solo tocan aplicaciones estándar de Office con los conectores básicos. En cuanto un flujo cruza la línea de los conectores premium (SQL Server, Salesforce, SAP, Dataverse, HTTP, conectores a medida), deja de ser gratis y pide una licencia de pago. Y esa línea se cruza casi siempre, porque el trabajo de verdad rara vez se queda dentro de Office.
El modelo de licencia tiene, a día de 2026, tres formas principales, y elegir mal cuesta dinero al escalar. La licencia por usuario deja a una persona correr todos los flujos que quiera; sale a cuenta cuando pocos usuarios necesitan capacidades premium. La licencia por flujo (o por proceso) paga por un flujo concreto sin importar cuánta gente lo dispare; gana cuando un mismo flujo lo usa mucha gente. Y la RPA desatendida —un bot que corre solo, sin nadie delante— se licencia aparte, por bot, y es la partida más cara con diferencia. A esto se suma el on-premises data gateway si necesitas que un flujo en la nube toque un dato que vive en tu servidor: es una capacidad premium, no un extra gratis.
| Modelo | Qué paga | Cuándo sale a cuenta |
|---|---|---|
| Por usuario | Que una persona corra flujos premium ilimitados | Pocos usuarios con necesidades premium |
| Por flujo / proceso | Un flujo concreto, lo dispare quien lo dispare | Un flujo que usa mucha gente |
| RPA desatendida | Un bot que corre solo, sin persona delante | Robotizar legacy a volumen (la partida cara) |
| Data gateway | Puente a datos on-premise desde la nube | Flujos que tocan tu servidor, no solo Office |
La disciplina es la misma que la de calcular el ROI de una automatización: no mires el precio de entrada —el "ya lo tienes con tu 365"—, costea al volumen y al tipo de flujo que vas a correr dentro de un año, con conectores premium y RPA incluidos si los vas a necesitar. "Incluido" que se dispara en cuanto tocas un sistema real no es gratis; es una decisión de coste que pagas más tarde.
Cloud flows y desktop flows: dos herramientas con el mismo nombre
Un detalle que confunde a quien llega nuevo: bajo el nombre "Power Automate" viven dos productos distintos. Los cloud flows corren en la nube de Microsoft y conectan aplicaciones por API —esto es lo que compite con Make, n8n o Zapier, y para elegir entre esas dos familias vale el mismo criterio de Make vs n8n—. Los desktop flows son RPA: un robot que se instala en una máquina y maneja aplicaciones de escritorio imitando a un humano —abre la pantalla, hace clic, teclea, copia—. Sirven justo para lo contrario: sistemas que no tienen API y con los que solo se puede hablar por la interfaz.
La diferencia importa al decidir, porque cada uno resuelve un problema y cada uno se paga distinto. Si tu automatización conecta aplicaciones modernas con API, quieres cloud flows y compites en el terreno del no-code de siempre. Si tu automatización tiene que pelearse con un programa viejo sin API, quieres desktop flows y estás en el terreno del RPA, que es más frágil por diseño: un cambio en la pantalla del sistema legacy rompe el robot. Esa fragilidad es exactamente lo que convierte el mantenimiento de las automatizaciones en la partida que nadie presupuesta —y en RPA pesa el doble.
Dónde Power Automate se queda corto (y qué mirar entonces)
Power Automate es un motor de flujos excelente, pero tiene dos techos que conviene ver antes de casarte con él. El primero es el techo de criterio: por diseño ejecuta reglas, no decide sobre contexto ambiguo. Copilot te ayuda a montar el flujo y AI Builder sabe leer un documento con formato conocido, pero cuando el trabajo exige leer texto libre, entender la intención de un correo o cuadrar lo que no casa entre tres sistemas, Power Automate se queda en el borde. Ahí no necesitas un flujo más largo: necesitas una capa de decisión —modelos de lenguaje con la lógica alrededor— montada encima, que es de lo que va de verdad automatizar con IA frente a la automatización clásica.
El segundo es el techo de la casa cerrada: Power Automate es de Microsoft y brilla dentro de Microsoft. En cuanto tu operación vive medio fuera —tu CRM es HubSpot, tu producto corre en Google Cloud, tu equipo trabaja en Notion y Slack— fuerzas la herramienta a cruzar fronteras donde otras opciones son más naturales y más baratas. No es que no pueda; es que dejas de aprovechar su única gran ventaja (la integración nativa con Office) y te quedas con sus costes. Cuando el flujo tiene que hablar con sistemas de fuera, el problema real ya no es la herramienta sino integrar la IA con tus sistemas sin que se rompa cuando uno cambia por su cuenta.
| Tu situación | Power Automate | Mirar también |
|---|---|---|
| Todo en Microsoft 365, flujos de Office | Encaje natural | — |
| Aprobaciones y avisos internos | Difícil de superar | — |
| Legacy sin API (RPA) | Desktop flows, terreno propio | UiPath, Automation Anywhere |
| Conectar apps modernas con API | Cloud flows, funciona | Make, n8n, Zapier |
| Decisión sobre texto/contexto | Se queda en el borde | Capa de IA a medida encima |
| Stack medio fuera de Microsoft | Fuerzas la herramienta | Opciones neutrales al proveedor |
Entonces, ¿Power Automate sí o no?
La versión honesta: sí si tu empresa vive dentro de Microsoft 365, tus automatizaciones son mover datos de Office, lanzar aprobaciones o robotizar un sistema legacy, y tienes claro el modelo de licencia antes de escalar. Con matices si tu stack está medio fuera o si el trabajo exige criterio de verdad: ahí Power Automate puede ser una pieza —el brazo que ejecuta dentro de Office— pero no el sistema entero, y la decisión de fondo vuelve a ser qué procesos automatizar y con qué encaje, no qué herramienta comprar. La marca es la última decisión, no la primera.