Power Automate y PowerShell + Programador de tareas: cuándo usar cada uno ── conectar las herramientas de automatización sin mezclarlas, cada una en su lugar

«En el servidor de contabilidad llevamos casi diez años con procesos por lotes nocturnos de PowerShell funcionando. Por otro lado, últimamente el personal de las áreas operativas ha empezado a crear flujos de solicitud y de notificación con Power Automate. Aunque ambos son “automatización”, han ido creciendo dentro de la empresa dos líneas completamente distintas en cuanto a forma de construirlas y a dónde residen, y ya no sabemos con cuál deberíamos crear la próxima automatización, ni siquiera quién tiene una visión de conjunto de todo esto». Últimamente recibimos con frecuencia consultas así de pymes que ya han implantado Microsoft 365.

PowerShell + Programador de tareas y Power Automate son, ambos, herramientas para “ejecutar automáticamente un trabajo determinado”, pero sus ámbitos de especialización apenas se solapan. Precisamente porque no se solapan, forzar todo hacia uno de los dos resulta incómodo, y mezclarlos sin fijar límites produce un remiendo imposible de mantener. En este artículo, tras ordenar las diferencias de carácter entre ambos, explicamos los criterios para decidir con cuál construir cada automatización y los patrones de conexión para cuando conviene mezclarlos. El diseño general de Power Automate se trata en «Automatizar procesos empresariales con Power Automate ── cuándo usar flujos de nube o de escritorio y diseño del manejo de errores», y una introducción a PowerShell propiamente dicho se trata en «Fundamentos de los comandos de PowerShell ── operaciones básicas y uso seguro», así que aquí nos centramos en “el criterio de elección” y en “la integración”.

1. Conclusión por adelantado

• El primer criterio de decisión es dónde está el objeto. Si el objeto son archivos locales, carpetas compartidas, servidores o el propio sistema operativo, la línea base es PowerShell + Programador de tareas; si el objeto son datos de Microsoft 365 como SharePoint, Outlook o Teams junto con notificaciones y aprobaciones, la línea base es Power Automate.
• El punto débil de PowerShell es la notificación a personas. El popular Send-MailMessage está marcado oficialmente como obsoleto y no tiene un sustituto directo dentro de PowerShell.¹ Dejar las notificaciones y aprobaciones a cargo de Power Automate resulta más económico.
• El punto débil de Power Automate es el alcance hacia entornos locales (on-premises) y los grandes volúmenes de datos. Para que un flujo de nube llegue hasta un servidor de archivos interno hace falta una puerta de enlace de datos local o la integración con un flujo de escritorio, y ambas quedan fuera del derecho de uso incluido con Microsoft 365 (son funciones premium).²³⁴
• Si se van a conectar ambos, la primera opción es un acoplamiento débil en el que PowerShell coloca el archivo de resultado en SharePoint y Power Automate lo detecta con el disparador «Cuando se crea un archivo (solo propiedades)» (en la interfaz en inglés, When a file is created (properties only)) para enlazarlo con una notificación o una aprobación.⁵
• Power Automate for desktop cuenta con la acción «Ejecutar script de PowerShell», que permite llamar a scripts existentes desde un flujo. Sin embargo, invocarla desde un flujo de nube es una función premium, y también hace falta administrar la máquina de ejecución.⁶⁴
• El historial de ejecución de un flujo de nube solo se conserva 28 días de forma predeterminada.⁷ Para los procesos que requieren evidencia, hay que conservarla mediante un archivo de log en el lado de PowerShell o escribiéndola de vuelta en una lista de SharePoint.
• Al final, la respuesta correcta muchas veces no depende de la tecnología, sino de construirlo con la herramienta para la que sí hay alguien capaz de mantenerla. Una automatización que solo puede corregir la persona que la creó es el mismo riesgo, sea cual sea la herramienta.

2. El carácter de las dos herramientas

Primero conviene confirmar que ambas son herramientas de ámbitos completamente distintos.

Conviene añadir algo sobre la fila «Gestión de cambios» de la tabla. Exportar un flujo consiste en iniciar sesión en el portal de Power Automate, seleccionar el flujo deseado en «Mis flujos» > «Flujos de nube» del panel de navegación izquierdo, y en el menú elegir «Paquete (.zip)» desde la flecha hacia abajo que hay junto a «Exportar». Lo que se obtiene es un paquete zip, poco adecuado para una revisión de diferencias línea por línea como la de un script. Además, existe la restricción de que solo el propietario o los copropietarios del flujo pueden exportarlo. Si se quiere llevar un control de versiones continuo, Microsoft recomienda un ALM basado en soluciones de Dataverse, en lugar de la exportación/importación de paquetes.⁸

Lo importante es que, en esta tabla, tanto el “lugar de ejecución” como “quién lo crea” son distintos entre ambas columnas. PowerShell + Programador de tareas se ejecuta en máquinas internas de la empresa, lo crea alguien que sabe programar y se gestiona como código. Power Automate se ejecuta en la nube, lo puede crear incluso una persona de las áreas operativas sin ser experta técnica, y no hace falta ocuparse de la infraestructura de ejecución. Es decir, que ambos convivan no es una simple duplicación de herramientas, sino la coexistencia de dos culturas: “la automatización de TI” y “la automatización de las áreas operativas”. Precisamente por eso, intentar unificarlo todo hacia un solo lado con una simple orden desde arriba suele fracasar.

3. Tabla de decisión sobre con qué herramienta construir cada automatización

Cuando recibimos una consulta, distinguimos los casos con tres preguntas: “dónde está el objeto”, “quién lo va a crear y mantener” y “si hace falta notificación o aprobación dirigida a personas”. Es más rápido verlo con ejemplos concretos de trabajo, así que lo presentamos como una tabla de decisión.

Si se recorre la columna verticalmente, se ve que la herramienta queda determinada casi en una relación uno a uno con la columna “objeto”. La excepción son casos que cruzan ambos mundos, como el de la última fila, donde “el procesamiento es local pero la notificación es en la nube”; ahí es donde entran en juego los patrones de integración del capítulo 6.

Por el contrario, las siguientes formas de elegir se vuelven incómodas más adelante.

• Llevar incluso el procesamiento de archivos a Power Automate solo porque se quieren notificaciones. Introducir una puerta de enlace o RPA para lograr el alcance on-premises aumenta tanto las licencias como los objetos que hay que administrar (capítulo 5).
• Que TI construya en PowerShell el flujo de solicitud de SharePoint que usan las áreas operativas. Se puede construir, pero escribir en código la escritura en SharePoint o la notificación por Teams cuesta mucho trabajo para lo poco que se gana, y termina siendo una pieza única que las áreas operativas no pueden tocar.
• Elegir de forma dispersa según cada responsable, con el argumento de que “con cualquiera de las dos se puede hacer”. Esto conecta directamente con el problema de mantenimiento que se trata en el capítulo 7. Basta con fijar una única regla interna del tipo “si el objeto está aquí, la herramienta es esta” para contener bastante el desorden de la convivencia.

4. Límites del lado de PowerShell

Las notificaciones por correo y Teams son un problema

En cuanto un proceso por lotes nocturno de PowerShell recibe la petición de “avisar por correo cuando termine”, el asunto se complica de golpe. El cmdlet Send-MailMessage, usado durante años, está marcado oficialmente como obsoleto porque no puede garantizar una conexión segura al servidor SMTP, y el texto de advertencia indica explícitamente que “no existe un sustituto directo dentro de PowerShell”. Como alternativas se recomiendan la biblioteca de terceros MailKit, o el Microsoft Graph PowerShell SDK (Send-MgUserMail) para usuarios de Exchange Online.¹

El envío a través de Graph funciona, pero cargar con el registro de una aplicación en Microsoft Entra ID, la concesión de permisos (scopes) y la administración de un certificado o secreto, solo para una notificación, supone bastante preparación. Con las notificaciones a Teams pasa algo parecido: llamarlas directamente desde código implica una barrera de entrada alta en materia de autenticación. Aquí lo recomendable es, sin más, decidir que las notificaciones queden a cargo de Power Automate. Con las acciones estándar de los conectores de Outlook y Teams se pueden montar en pocos minutos, sin necesidad de registrar ninguna aplicación adicional.

Las “tareas silvestres” que corren en el PC de un responsable

Un accidente frecuente en las automatizaciones del Programador de tareas es que la tarea está instalada no en un servidor, sino en el PC de un responsable. Si esa persona apaga el PC al irse, la tarea no se ejecuta, y se detiene silenciosamente cuando cambia la contraseña del usuario de ejecución o cuando esa persona deja la empresa. Además, como el Programador de tareas es local a cada máquina, no existe un sitio donde ver de un vistazo qué está funcionando y dónde dentro de la empresa.

Las medidas son poco vistosas pero son estas tres: (1) centralizar las tareas de ejecución programada en un servidor fijo (o, si no lo hay, en un PC de administración siempre encendido); (2) documentar el listado de tareas junto con su propósito y responsable; (3) dejar la propia definición de la tarea como un script, por ejemplo con Register-ScheduledTask, para poder reproducirla aunque cambie la máquina.⁹ Aunque solo el cuerpo del script esté bajo control de Git, si la configuración del Programador de tareas (hora de inicio, usuario de ejecución, carpeta de trabajo) se sigue haciendo a mano, no se puede reproducir el entorno.

El almacenamiento de credenciales

Cuando un script se conecta a una base de datos o a un servicio externo, siempre surge el problema de dónde guardar la contraseña. Escribirla directamente en el .ps1 queda descartado de entrada; la respuesta estándar de PowerShell es el módulo SecretManagement junto con la extensión SecretStore. Permite guardar los secretos cifrados de forma local y recuperarlos desde el script con Get-Secret.¹⁰ También hay documentación oficial sobre la configuración necesaria para usarlo en una ejecución desatendida desde el Programador de tareas, configurando el contexto de una cuenta de automatización.¹¹ Cabe señalar que este conjunto de módulos se considera actualmente “con funcionalidad completa” y ya no recibe desarrollo de nuevas funciones, aunque sí continúa el soporte de correcciones de seguridad.¹⁰

Power Automate, en cambio, hace que sea la propia plataforma quien mantenga la conexión (autenticación) con el conector, de modo que quien construye el flujo no necesita preocuparse por este problema. Se trata de una fortaleza poco visible de Power Automate, aunque, dicho de otro modo, genera otro problema de gestión distinto: que la conexión queda ligada a la cuenta del propietario del flujo. Este punto se trata en «Cómo evitar la dependencia de una sola persona en Power Automate ── para que un flujo no se detenga aunque quien lo creó se vaya».

5. Límites del lado de Power Automate

No llega a archivos locales ni a entornos on-premises

Como los flujos de nube se ejecutan en la nube de Microsoft, no llegan tal cual a las carpetas compartidas de la red interna de la empresa ni a bases de datos on-premises. Hay principalmente dos formas de alcanzarlos.

1. Puerta de enlace de datos local (on-premises data gateway). Consiste en instalar una aplicación residente dentro de la empresa que actúa de puente con la nube. Es un mecanismo bastante seguro porque no requiere abrir puertos de entrada y funciona solo con conexiones de salida.¹² A través de la puerta de enlace se puede conectar con el sistema de archivos, SQL Server, etc., pero para usarla hace falta una licencia que la admita.²
2. A través de un flujo de escritorio (RPA). Consiste en llamar desde un flujo de nube a un flujo de escritorio que se ejecuta en un PC, y dejarle el procesamiento local. Esta propia capacidad de “disparar y programar la ejecución desde un flujo de nube” ya es una función premium.⁴

Lo importante es que ambas opciones quedan fuera del derecho de uso de Power Automate incluido con Microsoft 365. El derecho de uso que viene incluido con Microsoft 365 (seeded license) no incluye ni conectores premium, ni la puerta de enlace on-premises, ni RPA.³ Es decir, “querer procesar con Power Automate los archivos de una carpeta compartida” es una petición que sale más cara de lo que parece a simple vista. Los niveles de licencia y el límite entre lo estándar y lo premium se explican en «Licencias de Power Automate y el límite entre conectores estándar y premium», así que conviene revisarlo antes de decidir.

Hay dos soluciones realistas sin costo adicional: trasladar el lugar donde se guardan los archivos objetivo a SharePoint/OneDrive, o dejar el procesamiento del lado de la carpeta compartida a cargo de PowerShell y que Power Automate se ocupe únicamente del trabajo del lado de la nube. Esta segunda opción es el patrón de integración del siguiente capítulo.

Los grandes volúmenes de datos y la lógica compleja son un problema

Un procesamiento que recorre línea por línea, con un bucle del flujo, un CSV de cientos de miles de filas, queda fuera del ámbito de diseño de Power Automate. También hay un límite diario de acciones ejecutadas según la licencia: con el derecho de uso incluido en Microsoft 365 son 6.000 acciones por usuario al día.³ El cotejo, la agregación y la transformación de grandes volúmenes son procesos que, escritos en PowerShell o .NET, pueden terminar en pocos minutos. Para la forma concreta de escribirlo sirve tal cual la combinación de Group-Object y Compare-Object que se trató en «Recetario práctico de comandos de PowerShell ── suma pequeñas funciones que se usan a diario».

Además, una lógica con ramificaciones condicionales muy anidadas es difícil de leer en la pantalla del flujo y no se le pueden escribir pruebas. El límite de que un flujo de nube dure como máximo 30 días por ejecución¹³ afecta a las esperas de aprobación, pero, incluso antes de eso, una “lógica cuyas ramas, dibujadas en papel, no caben en una hoja A4” pertenece al terreno del código.

El historial de ejecución desaparece a los 28 días

El historial de ejecución de un flujo de nube solo se muestra, de forma predeterminada, durante 28 días.⁷ Para un requisito del tipo “quiero comprobar dentro de tres meses si el proceso por lotes de aquel día se ejecutó”, el historial de ejecución no sirve. Con PowerShell, en cambio, se puede escribir un archivo de log propio y conservarlo durante años (este diseño se detalló en el artículo sobre mantenimiento de logs). Cuando en Power Automate hace falta evidencia, hay que incorporar al propio flujo un paso que escriba de vuelta el resultado del procesamiento en una lista de SharePoint. Para una construcción más completa, incluyendo notificaciones de error y reintentos, consulte «Diseño del manejo de errores y reintentos en Power Automate».

6. Patrones de conexión al mezclar ambas herramientas

Dado que los ámbitos de especialización de ambas no se solapan, siempre acaban apareciendo trabajos que cruzan ambos mundos: “el procesamiento en PowerShell, la notificación y la aprobación en Power Automate”. Hay tres patrones de conexión.

Patrón a: acoplamiento débil a través de archivos (recomendado)

El PowerShell que se ejecuta desde el Programador de tareas coloca el resultado del procesamiento (CSV de resultados, resumen) en una biblioteca de SharePoint, y el lado de Power Automate lo detecta con el disparador «Cuando se crea un archivo (solo propiedades)» del conector de SharePoint, para enlazarlo con una notificación o una aprobación. Este disparador existe realmente como disparador de un conector estándar, y los cambios se recogen en un plazo aproximado de pocos minutos (no es instantáneo, porque el mecanismo consiste en sondear periódicamente los cambios del lado de SharePoint).⁵

Si el idioma de visualización del inquilino (tenant) está en inglés, no se podrá buscar por este nombre en español, así que se indica también el nombre en la interfaz en inglés. Al buscarlo en la lista de disparadores, utilice esta referencia.⁵

Cabe destacar que el disparador de nombre parecido «Cuando se crea un archivo (en una carpeta)» (When a file is created in a folder) está obsoleto y tiene restricciones, como no activarse en subcarpetas, así que no lo elija si va a construir algo nuevo.⁵

El siguiente diagrama representa el flujo de este patrón: el Programador de tareas inicia el script de PowerShell a las 02:00 → el script realiza la agregación, el procesamiento de archivos y la escritura de logs, y genera el CSV de resultados y el resumen → eso se coloca en una biblioteca de SharePoint → la colocación es detectada por el disparador «Cuando se crea un archivo» y se inicia el flujo de nube → el flujo revisa el contenido del resumen: si terminó con normalidad, envía una notificación de finalización a Teams, y si hubo un error, notifica al responsable y, si hace falta, lo deriva a un flujo de aprobación o atención; es decir, un flujo en una sola dirección.

flowchart TD
    T[Programador de tareas: inicio a las 02:00] --> PS[Script de PowerShell<br/>agregación, procesamiento de archivos y registro de logs]
    PS --> OUT[Genera el CSV de resultados y el resumen]
    OUT --> UP[Se coloca en la biblioteca de SharePoint]
    UP --> TRG[Inicio del flujo de nube<br/>Cuando se crea un archivo]
    TRG --> CHK{Contenido del resumen}
    CHK -- Finalización normal --> OK[Notificación de finalización a Teams]
    CHK -- Hay error --> NG[Notifica al responsable<br/>si hace falta, deriva a aprobación/atención]

Figura 1: flujo del patrón de acoplamiento débil a través de archivos, entre PowerShell y Power Automate.

El método para colocar el archivo desde PowerShell en SharePoint se elige según cómo se ejecute la tarea. La forma más sencilla es que la carpeta de salida esté sincronizada con OneDrive/SharePoint (el script solo tiene que escribir en la carpeta local), pero el cliente de sincronización es una aplicación que funciona dentro de la sesión de un usuario con la sesión iniciada. En una tarea nocturna configurada como “ejecutar independientemente de si el usuario ha iniciado sesión o no”, o en un servidor donde nadie tiene la sesión iniciada, la sincronización no funciona, y se produce un fallo silencioso: el archivo escrito localmente nunca se sube y el flujo tampoco llega a iniciarse. Para una operación pequeña que se ejecuta de día en un PC con alguien presente, la sincronización es suficiente, pero si se parte de una ejecución nocturna y desatendida, hay que usar PnP.PowerShell o la API de Graph para subir el archivo directamente desde el script, o bien preparar una sesión que permanezca con el inicio de sesión activo para la sincronización e incluirla en el monitoreo. Esto añade preparación de autenticación, pero elimina de raíz el problema de “el archivo que debería estar ahí no está”.

PnP.PowerShell es un módulo de PowerShell de código abierto creado por la comunidad (no es un producto oficial de Microsoft) para operar SharePoint Online, Teams y otros servicios de Microsoft 365. Cuenta con más de 700 cmdlets y permite subir archivos u operar listas directamente desde un script. Sin embargo, lo que antes se podía conectar fácilmente con una aplicación de Entra ID compartida dejó de ser posible: en septiembre de 2024 esa aplicación se retiró, y ahora es obligatorio que cada usuario registre su propia aplicación de Entra ID. Ya no es un caso de “instalar el módulo y que funcione de inmediato”, así que, al decidir si adoptarlo, hay que contar también con el esfuerzo de este registro de aplicación y la concesión de permisos.¹⁴

La razón para recomendar este patrón es que el límite queda fijado de forma visible en un archivo. El lado de PowerShell no sabe que existe Power Automate, y el lado de Power Automate no conoce el contenido del script. Cuando uno de los dos falla, basta con mirar si el archivo está en SharePoint para aislar de inmediato de qué lado viene el problema. También se puede repartir la responsabilidad: la división del trabajo, con el script a cargo de TI y el flujo de notificación a cargo de alguien de las áreas operativas que lo conozca bien, funciona tal cual. Además, el propio archivo colocado sirve como evidencia que compensa el problema de los 28 días del historial de ejecución.⁷

Patrón b: llamar a PowerShell desde Power Automate for desktop

Power Automate for desktop (PAD) cuenta con la acción «Ejecutar script de PowerShell (Run PowerShell script)», que permite ejecutar cualquier código de PowerShell dentro de un flujo de escritorio y recibir la salida en una variable (PowershellOutput).⁶ Como se puede llamar a un script existente como una pieza más del flujo, se puede montar una configuración en la que “el cuerpo del procesamiento sigue siendo el script, y solo el inicio y las operaciones de pantalla anteriores y posteriores quedan a cargo de PAD”.

Esta acción tiene solo tres opciones de configuración.⁶

La salida se recibe en dos variables: PowershellOutput (la salida del script) y ScriptError (los errores producidos durante la ejecución). La forma oficial de devolver un valor al flujo es pasarlo a Write-Output en el lado de PowerShell.⁶

# Ejemplo mínimo pensado para pegar en el campo "PowerShell code to run" de la acción de PAD.
# %InputFolder% es una variable del lado de PAD que se sustituye por una cadena antes de que se ejecute PowerShell
$targetFolder = '%InputFolder%'
$count = (Get-ChildItem -LiteralPath $targetFolder -Filter '*.csv' -File).Count

# Lo que se devuelve con Write-Output queda en la variable PowershellOutput
Write-Output $count

Es decir, visto desde el lado de PAD, esta pieza solo tiene dos puntos: la entrada, “las variables incrustadas en el cuerpo del código”, y la salida, “la cadena de PowershellOutput”. Como el valor de retorno no llega estructurado, sino como una cadena de texto, si se quieren devolver varios valores el diseño consiste en reunirlos en una línea de CSV o en JSON dentro de PowershellOutput y analizarlos después. Contando también que el tiempo de espera predeterminado es de solo 10 segundos, no es adecuado para el uso de “cargar el cuerpo entero de un proceso por lotes nocturno en esta única acción”. Para procesos largos, decida teniendo en cuenta también los puntos de atención que se indican a continuación.

Sin embargo, hay tres puntos de atención. Primero, esta acción inicia internamente powershell.exe, es decir, Windows PowerShell 5.1.¹⁵ Un script escrito asumiendo PowerShell 7 puede no funcionar tal cual. Segundo, existe una configuración de tiempo de espera (valor predeterminado de 10 segundos), y si se va a llamar a un proceso por lotes largo hay que ampliarlo explícitamente o dejarlo sin límite.⁶ Tercero, si se quiere ejecutar esto de forma programada y desatendida, el disparador desde un flujo de nube es una función premium,⁴ y además hace falta una licencia de ejecución desatendida y la administración de la máquina de ejecución. Conviene analizar con calma si vale la pena pagar el costo adicional de “ejecutar de forma programada con PAD en lugar del Programador de tareas”. Es una opción viable para una empresa que ya opera RPA (manejo de pantalla) con PAD y tiene la infraestructura de ejecución lista, pero si no es el caso, el patrón a resulta suficiente.

Patrón c: una API propia que recibe solicitudes HTTP

Es un método en el que el flujo de nube tiene su propia URL gracias al disparador «Al recibir una solicitud HTTP (When an HTTP request is received)», y se invoca desde el lado de PowerShell llamándola con Invoke-RestMethod; o, al revés, se levanta una pequeña API web dentro de la empresa y se la llama desde el flujo. Este disparador pertenece al conector premium de solicitud/respuesta HTTP.¹⁶ También existe un mecanismo de autenticación OAuth que permite configurar restricciones sobre quién puede llamarlo, por ejemplo, solo usuarios del propio inquilino.¹⁷

Es el patrón más flexible, con alta capacidad de tiempo real y posibilidad de pasar parámetros, pero de golpe hay que pensar en la gestión de la URL, la autenticación y el reenvío en caso de error, es decir, entra de lleno en el terreno del desarrollo. Llegados a este punto, ya no se trata de “integrar Power Automate y PowerShell”, sino de un pequeño desarrollo de sistema, así que es un momento para decidir si se asume internamente o si conviene que alguien externo revise el diseño.

En resumen: primero el patrón a; el b, si ya existe la infraestructura de PAD; y el c, solo cuando el requisito de tiempo real está claro. El diseño de acoplamiento débil es aplicable a la integración de archivos en general, y las prácticas de control de exclusión mutua y de entrega también se tratan en «Conocimientos básicos del control de exclusión mutua en la integración de archivos - mejores prácticas de bloqueo de archivos y de reclamo atómico (claim)».

7. El problema de “no hay nadie que sepa hacer las dos cosas”

Hasta aquí hemos escrito los criterios de decisión en términos técnicos, pero lo que termina pesando en la práctica es “quién puede mantenerlo”. Una persona que sabe escribir PowerShell en TI, una persona que sabe manejar Power Automate en las áreas operativas, y cero personas que dominen ambas cosas: en las pymes esto es lo normal.

Por eso, aunque un proceso sea técnicamente más adecuado para PowerShell, decidir construirlo en Power Automate porque la persona que sabe escribirlo tiene previsto dejar la empresa (o al revés) es una decisión perfectamente razonable. Más que la superioridad de una herramienta sobre otra, importa más si dentro de cinco años habrá alguien en la empresa capaz de corregirlo. La tabla de decisión (capítulo 3) es “la solución óptima suponiendo que hay alguien capaz de mantenerlo”; si no hay esa persona, hay que doblar la solución óptima para adaptarla a las personas disponibles.

Dicho esto, hay dos cosas que conviene hacer sin importar cuál de las dos herramientas se use.

• Inventariar la existencia de todo. Reunir en un mismo registro el listado de tareas del Programador de tareas (en qué máquina, a qué hora, qué hace y bajo la administración de quién) junto con el listado de flujos de Power Automate (propietario, conexiones, propósito). En una empresa donde conviven las dos líneas, lo más peligroso es que una de ellas quede invisible para la otra.
• Guardarlo de forma que se pueda transferir. Los scripts en Git, las definiciones de tarea en un script de registro,⁹ y los flujos con la configuración de copropietarios y su exportación. Una automatización sin documentación equivale a producir en serie versiones a pequeña escala de un sistema sin código fuente ni documentación. El diseño concreto de la transferencia del lado de los flujos se resume en el artículo sobre cómo evitar la dependencia de una sola persona.

8. Resumen

PowerShell + Programador de tareas y Power Automate no son herramientas que compitan entre sí, sino herramientas distintas cuyos ámbitos de cobertura apenas se solapan. Lo local, los servidores, los archivos y los grandes volúmenes de datos van hacia PowerShell; los datos de Microsoft 365 junto con las notificaciones y aprobaciones van hacia Power Automate. Con esta línea base queda decidido el lugar de la mayoría de las automatizaciones.

Para el trabajo que cruza ese límite, en lugar de forzarlo hacia un solo lado, lo más sólido, tanto en términos de licencias como de mantenimiento, es conectarlo con un acoplamiento débil que use como límite un archivo colocado en SharePoint. La dificultad de PowerShell con las notificaciones (Send-MailMessage obsoleto) y la dificultad de Power Automate para llegar a lo on-premises (la puerta de enlace y la RPA son premium) se compensan mutuamente, cada una con el terreno en el que la otra destaca.

Y, con la misma importancia que la elección de la herramienta, hay que decidir de antemano “quién lo va a mantener” y “qué está funcionando y dónde”. Que convivan dos líneas de automatización no es en sí mismo un problema; el único problema es que se mezclen sin orden. También atendemos consultas desde la etapa en la que se quiere ordenar la visión de conjunto de la automatización interna de la empresa, o en la que se necesita una decisión caso por caso sobre con qué herramienta construir cada cosa.

Artículos relacionados

• Automatizar procesos empresariales con Power Automate ── cuándo usar flujos de nube o de escritorio y diseño del manejo de errores
• Las tareas del Programador de tareas no se ejecutan o terminan con 0x1 ── aislar la causa y diseñar una operación segura
• Aplicaciones de scripts de PowerShell ── automatizar de forma segura la investigación de logs, el archivado y la generación de informes
• Licencias de Power Automate y el límite entre conectores estándar y premium
• Cómo evitar la dependencia de una sola persona en Power Automate ── para que un flujo no se detenga aunque quien lo creó se vaya
• Diseño de flujos de ejecución periódica en Power Automate: determinación de días hábiles y procesos de fin de mes

Áreas de consultoría relacionadas

En KomuraSoft LLC atendemos consultas que van desde la puesta a punto de procesos por lotes internos con PowerShell hasta la revisión del diseño de una plataforma de automatización que incluya Power Automate, incluyendo el criterio de con qué herramienta conviene construir cada cosa.

• Consultoría técnica y revisión de diseño
• Desarrollo de aplicaciones Windows
• Contacto

Referencias

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Con qué herramienta se debería crear la automatización, Power Automate o PowerShell?

La base es dividir según dónde esté el objetivo. Si el objeto son archivos locales, carpetas compartidas, servidores, bases de datos u operaciones del sistema operativo, es decir, el entorno Windows interno de la empresa, PowerShell + Programador de tareas suele ser más estable y fácil de mantener. Si el objeto son datos de Microsoft 365 como SharePoint, Outlook o Teams, junto con notificaciones y aprobaciones, los flujos de nube de Power Automate son los más adecuados. También es realista separar el cuerpo del procesamiento de las notificaciones: el procesamiento pesado en PowerShell y las notificaciones o aprobaciones dirigidas a personas en Power Automate.

¿Es difícil enviar notificaciones por correo o Teams desde PowerShell?

El cmdlet Send-MailMessage, utilizado tradicionalmente, está marcado oficialmente como obsoleto porque no garantiza una conexión segura con el servidor SMTP, y no existe un sustituto directo dentro de PowerShell. Existe la opción de enviarlo con Send-MgUserMail del Microsoft Graph PowerShell SDK, pero requiere preparar el registro de una aplicación y la concesión de permisos, lo que supone una barrera de entrada alta si solo se va a usar para notificaciones. En la práctica, resulta más manejable que PowerShell se limite a escribir el resultado en un archivo, y que la detección y la notificación queden a cargo de Power Automate.

¿Se pueden procesar con Power Automate archivos de una carpeta compartida local?

Sí es posible, pero para que un flujo de nube llegue a archivos de la red interna de la empresa hace falta introducir una puerta de enlace de datos local (on-premises data gateway), y el derecho a usar dicha puerta de enlace no está incluido en el derecho de uso de Power Automate que viene con Microsoft 365, sino que requiere una licencia superior. Llamar a un flujo de escritorio (RPA) desde un flujo de nube también es una función premium. Si se quiere prescindir de licencias adicionales, lo más realista es estudiar primero si conviene trasladar los archivos objetivo a SharePoint/OneDrive, o bien dejar el procesamiento de la carpeta compartida a cargo de PowerShell + Programador de tareas.

¿Cuál es la forma más sencilla de conectar un proceso por lotes nocturno de PowerShell con Power Automate?

Se recomienda el acoplamiento débil a través de archivos. Es una configuración en la que el PowerShell que se ejecuta desde el Programador de tareas coloca el CSV o el archivo de resumen con el resultado del procesamiento en una biblioteca de SharePoint, y el lado de Power Automate lo detecta con el disparador «Cuando se crea un archivo (solo propiedades)» para enlazarlo con una notificación o una aprobación. Como ninguno de los dos mecanismos necesita conocer el interior del otro, si uno de ellos falla es fácil aislar el problema, y además se puede asignar el trabajo a personas distintas. También existe la opción de llamarlo directamente con la acción «Ejecutar script de PowerShell» de Power Automate for desktop, pero eso añade requisitos de licencia y de administración de la máquina.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.