Automatizar procesos empresariales con Power Automate — Cuándo usar el flujo en la nube o el de escritorio, y cómo diseñar el manejo de errores

«Todas las mañanas junto en Excel los CSV que se acumulan en una carpeta compartida y se los envío por correo a mi superior», «copio y pego manualmente valores de varios sistemas empresariales para consolidarlos». Últimamente recibo con frecuencia consultas de personas que quieren automatizar este tipo de tareas con Power Automate.

El primer flujo pequeño suele echarse a andar en cuestión de decenas de minutos. Lo complicado viene después. Al cabo de un tiempo funcionando en producción, empieza a detenerse de vez en cuando por un error. Basta con que cambie ligeramente el diseño de pantalla del sistema objetivo para que el flujo se rompa. La ubicación de la contraseña nunca quedó decidida y sigue escrita directamente en una variable de entrada, provisionalmente. Existe un «flujo que funciona», pero llegado el momento nadie puede repararlo: he visto varias veces proyectos que caen en esta situación.

Power Automate tiene un coste de aprendizaje bajo y se puede empezar sin código o con poco código. Precisamente por esa facilidad, es también una herramienta que tiende a llegar a producción sin haber resuelto antes el diseño. En este artículo recorremos, en el orden en que suelen surgir los problemas en la práctica, las diferencias entre el flujo en la nube y el de escritorio, el reparto de funciones con PowerShell y VBA, el manejo de errores, el criterio para estabilizar la automatización de UI, el tratamiento de las credenciales, la gobernanza y la operación, y por último cómo reconocer el momento en que conviene ir más allá de Power Automate.

1. Primero, la conclusión

• Power Automate se divide fundamentalmente en dos categorías: el flujo en la nube (conecta servicios en la nube mediante conectores) y el flujo de escritorio (un RPA que automatiza la operación de pantallas y aplicaciones de escritorio en Windows). La primera decisión de diseño consiste en determinar cuál de los dos necesita realmente.
• Si lo único que se busca es automatizar «tareas repetitivas en el PC», en muchos casos PowerShell es un candidato más natural que Power Automate Desktop. Cuando no es imprescindible hacer clic o escribir en pantallas, PowerShell suele ser más fácil de mantener y se presta mejor al control de versiones.
• Power Automate aporta más valor cuando es necesario operar las pantallas de sistemas existentes con poca integración por API, o cuando se quiere crear rápidamente flujos de notificación o aprobación usando los conectores de Microsoft 365 (Outlook, SharePoint, Teams, etc.).
• Para llevar una solución a producción, hay cuatro puntos que deben incorporarse al diseño desde el inicio: el manejo de errores (On Block Error), la estabilización de los selectores de UI, la gestión segura de credenciales y la gobernanza mediante políticas de DLP. Añadirlos después es la fuente de la mayoría de los incidentes.¹²
• La ejecución desatendida (unattended) requiere una licencia y unos requisitos previos distintos de los de la ejecución asistida (attended). Si se posterga el diseño de licencias, puede darse la situación de que algo funcione en el entorno de pruebas pero no se pueda poner en marcha en producción.³⁴

2. Panorama general de Power Automate

Power Automate no es tanto un producto único como una plataforma que reúne varios mecanismos de automatización.

flowchart TB
    accTitle: Componentes de Power Automate
    accDescr: Diagrama que muestra cómo Power Automate se divide en flujo en la nube, flujo de escritorio, minería de procesos y AI Builder, y cómo se subdividen a su vez el flujo en la nube (automatizado, programado, instantáneo, conectores) y el flujo de escritorio (ejecución asistida, desatendida, automatización de UI).
    PA[Power Automate]
    PA --> Cloud[Flujo en la nube]
    PA --> Desktop[Flujo de escritorio / RPA]
    PA --> Process[Minería de procesos]
    PA --> Builder[AI Builder]

    Cloud --> Auto[Flujo automatizado<br/>Activado por eventos]
    Cloud --> Sched[Flujo programado<br/>Ejecución periódica]
    Cloud --> Instant[Flujo instantáneo<br/>Inicio manual/botón]
    Cloud --> Connectors[Conectores<br/>SharePoint / Outlook / Teams / SQL, etc.]

    Desktop --> Attended["Ejecución asistida（attended）<br/>Se ejecuta frente al usuario"]
    Desktop --> Unattended["Ejecución desatendida（unattended）<br/>Se ejecuta en servidor/PC dedicado"]
    Desktop --> UIAuto[Automatización de UI<br/>Manejo de pantallas e integración con apps existentes]

• El flujo en la nube es un mecanismo que conecta servicios en la nube entre sí a través de conectores. Según el tipo de disparador, se clasifica en flujo automatizado (cuando ocurre un evento), flujo programado (ejecución periódica) y flujo instantáneo (inicio manual).
• El flujo de escritorio es un RPA (Robotic Process Automation) que opera directamente aplicaciones y pantallas de Windows. Puede invocarse desde un flujo en la nube o ejecutarse de forma independiente.⁵
• El flujo de escritorio se subdivide, a su vez, en ejecución asistida (attended), que se ejecuta con una persona frente a la pantalla, y ejecución desatendida (unattended), que se ejecuta sin intervención humana en un PC o servidor dedicado.⁴

La «máquina dedicada» de la ejecución desatendida no significa simplemente que no esté bloqueada. En Windows 10/11, la ejecución desatendida falla si queda cualquier sesión en estado bloqueado, sea o no la del usuario usado para la conexión. En Windows Server el alcance es algo más limitado: solo falla si queda bloqueada la sesión del mismo usuario usado para la conexión. Es habitual conformarse con «bloquear» o «desconectar» tras un trabajo de mantenimiento o una conexión RDP de otro administrador, pero es imprescindible asegurarse de que todos hayan «cerrado sesión».⁶

Al recibir una consulta, lo primero es separar «¿se trata de conectar servicios en la nube entre sí, o de operar una pantalla?». Solo con esa distinción el panorama se aclara bastante.

3. Cuándo usar flujo en la nube, flujo de escritorio, PowerShell y VBA

Aunque todos se llamen «automatización», sus fortalezas son bastante distintas.

Un malentendido frecuente en la práctica es pensar que «quiero automatizar = usemos Power Automate sin más». Operar mediante UI con Power Automate Desktop un sistema que ya cuenta con una API es, en realidad, un caso en el que llamar directamente a la API desde PowerShell o .NET resulta más estable. A la inversa, cuando es necesario operar la pantalla de un sistema empresarial antiguo sin API o de una aplicación Win32, la automatización de UI del flujo de escritorio se convierte en una opción realista.

Nota: Las limitaciones de Excel y VBA, así como los criterios para reemplazarlos, se explican también en el artículo «Qué es VBA: limitaciones, futuro, cuándo conviene reemplazarlo y patrones de migración realistas». También se aborda el patrón de combinar Office Scripts con Power Automate para los flujos de trabajo en Microsoft 365.⁷

4. Licencias — Lo imprescindible para la ejecución desatendida

El panorama general del sistema de licencias (el alcance de las licencias semilla incluidas en Microsoft 365, el límite entre conectores estándar y premium, si sale más barato contar con Premium o con Process, y los créditos de AI Builder) se ha reunido, junto con una tabla de decisión, en el artículo «Licencias de Power Automate — Hasta dónde es gratis con Microsoft 365 y cuándo se necesita Premium». Aquí nos limitamos a los tres puntos imprescindibles para poner en producción la ejecución desatendida, que es el tema de este artículo.³

Si no se desea preparar una máquina física propia, también existe la opción de Power Automate Hosted Process, que ejecuta de forma desatendida en máquinas y grupos de máquinas alojados por Microsoft.⁸

Un último principio, aplicable más allá de la ejecución desatendida: «con la licencia de quién se ejecuta» no depende de quién lo creó, sino de cómo se dispara (el flujo automatizado y el programado usan la del propietario, el flujo instantáneo activado por botón usa la de quien lo ejecuta, y el RPA desatendido usa la de la máquina). Esta correspondencia está resumida en una tabla en el artículo de licencias mencionado arriba. En cualquier caso, posponer el diseño de licencias lleva a la situación de «funcionaba en el entorno de pruebas pero no se puede poner en producción», así que conviene verificar estos tres puntos ya en la fase de PoC.

5. Diseño práctico — Agregar los CSV de una carpeta compartida en un informe de Excel y enviarlo por correo

Como ejemplo concreto, tomamos el caso habitual de la «creación de un informe diario».

Antes de nada, dejamos clara la naturaleza de este apartado. Lo que se presenta aquí no es un manual de pasos en pantalla, sino un diseño conceptual: cómo decidir la composición de las acciones, las variables, la división en subflujos y la limpieza posterior a un error. La disposición de pantallas y los pasos operativos de Power Automate for desktop cambian con la versión, así que lo fiable es seguir la documentación oficial; este artículo se centra en «qué acciones usar, con qué granularidad y con qué paso de variables». Para acercar el resultado a algo directamente construible, en 5.1 se incluye la lista de variables (nombre, tipo y ejemplo de valor) y en 5.2 la estructura de división en subflujos.

Además, en este artículo los nombres de las acciones se dan con el nombre de su UI en inglés. Para quienes trabajen con la interfaz en japonés, la tabla de acciones de más abajo indica ese nombre en inglés, y la nota al pie correspondiente remite a la referencia oficial de acciones en japonés para localizar el nombre equivalente en esa interfaz.¹⁰

Lo que se quiere lograr

1. Reunir los CSV del día que están en la carpeta compartida
2. Agregar el contenido y escribirlo en la plantilla de informe de Excel
3. Guardar el informe en la carpeta designada
4. Notificar a los interesados por correo electrónico
5. Si falla, notificar al responsable y dejar la causa registrada en el log

flowchart TD
    accTitle: Flujo de agregación diario de CSV a informe de Excel
    accDescr: Diagrama que muestra el flujo desde el inicio programado, la obtención y agregación de los CSV del día, la escritura en Excel, el envío del correo y el registro, hasta el manejo de errores mediante On Block Error y el controlador de errores correspondiente.
    Start([Inicio programado 06:30]) --> Block[[On Block Error: Procesamiento de agregación]]
    Block --> List[Get files in folder<br/>Obtener los CSV del día]
    List --> Check{¿Hay archivos objetivo?}
    Check -- No --> NoticeEmpty[Registrar que no hay archivos y finalizar]
    Check -- Sí --> Read[Read from CSV file<br/>Recorrer archivo por archivo]
    Read --> Agg[Agregar valores y sumarlos a la variable]
    Agg --> Excel[Launch Excel<br/>Abrir la plantilla]
    Excel --> Write[Write to Excel worksheet<br/>Escribir los resultados agregados]
    Write --> Save[Guardar y cerrar Excel]
    Save --> Mail[Send an email<br/>Enviar el informe al responsable]
    Mail --> Log[Añadir el resultado de la ejecución al archivo de registro]
    Log --> End([Finalización normal])
    Block -. Error producido .-> Handler[Controlador de errores]
    Handler --> CloseExcel[Cerrar Excel si sigue abierto]
    CloseExcel --> LogErr[Registrar el contenido del error]
    LogErr --> Notify[Correo de notificación de fallo al administrador]
    Notify --> End2([Registrar como finalización anormal])

A continuación se listan las principales acciones y su función.

En japonés, este nombre tampoco tiene una correspondencia perfectamente unívoca; por ejemplo, Send an email (V2) de Office 365 Outlook aparece traducido de forma inconsistente incluso dentro de la documentación oficial en japonés, unas veces como «電子メールの送信 (V2)» y otras como «メールを送信する (V2)». Si no encuentra la acción en la UI, lo más fiable es buscarla por su nombre en inglés.¹²

5.1 Diseño de variables — Nombre, tipo y ejemplo de valor

El criterio para las variables es si «alguien que lea el flujo más adelante puede seguir su significado solo con verlo». En este ejemplo, como mínimo conviene decidir de antemano lo siguiente. Adapte los valores a su propio entorno.

Hay tres puntos clave: no escribir las rutas directamente dentro de las acciones, sino sacarlas a variables (así el intercambio entre el entorno de pruebas y producción se resuelve en un solo lugar); mantener separados el tipo fecha-hora y el texto para mostrar (la comparación se hace con el tipo fecha-hora, y el nombre de archivo se construye como texto); y tener siempre variables de recuento (sirven de material para el log y permiten distinguir entre «finalización normal con 0 elementos» y «0 elementos porque falló la obtención»).

5.2 División en subflujos

En lugar de convertir todo el flujo en una única secuencia gigantesca de acciones, dividirlo en subflujos por unidad de procesamiento facilita tanto las modificaciones posteriores como la reejecución de solo la parte que falló. En este ejemplo, la estructura sería la siguiente.

Main (flujo principal)
  ├─ Inicialización: definir las variables de 5.1
  ├─ Inicio del bloque [On Block Error]
  │    ├─ Ejecutar "Reunir CSV"            → salida: lstFiles
  │    ├─ Si hay 0 elementos, registrar "sin elementos" y finalizar
  │    ├─ Ejecutar "Agregar"                → entrada: lstFiles / salida: numTotal, numProcessed
  │    ├─ Ejecutar "Escribir en Excel"      → entrada: numTotal, txtTemplatePath / salida: txtReportPath
  │    ├─ Ejecutar "Notificar"              → entrada: txtReportPath, numProcessed
  │    └─ Ejecutar "Escribir log"           → entrada: resultado de ejecución (éxito)
  └─ [Controlador de errores]
       ├─ Ejecutar "Limpiar Excel" (cerrar la instancia si sigue abierta)
       ├─ Ejecutar "Escribir log"           → entrada: resultado de ejecución (fallo + detalle del error)
       └─ Ejecutar "Notificar"              → entrada: notificación de fallo para el administrador

El criterio de división es «¿se puede reejecutar de forma aislada sin romper nada?». Elementos como «Escribir log» o «Notificar», que se invocan tanto desde el camino normal como desde el de error, conviene convertirlos en subflujo desde el principio, para no gestionar el mismo proceso dos veces. A la inversa, si entre subflujos se empieza a depender de variables globales implícitas, es señal de que se ha dividido demasiado, y conviene volver a una granularidad en la que la entrada y la salida se pasen explícitamente.

Una configuración en la que el disparo programado se hace desde el flujo en la nube, y el procesamiento real se delega al flujo de escritorio invocado, también resulta cómoda de operar.⁵

6. Diseñar el manejo de errores

Power Automate Desktop cuenta con la acción On Block Error, que permite agrupar el manejo de errores por bloque. En lugar de configurar el «comportamiento ante errores» en cada acción individual, se puede aplicar un manejo de errores común a todas las acciones incluidas en el bloque.¹

[On Block Error] Bloque de procesamiento de agregación
  ├─ List files in folder
  ├─ Read from CSV file (bucle)
  ├─ Launch Excel / Write to Excel worksheet
  └─ Save Excel / Close Excel

[Controlador de errores]
  ├─ Obtener con la acción Get last error el contenido del error (nombre, lugar, acción implicada, mensaje detallado) como variable
  ├─ Cerrar la instancia de Excel si sigue abierta (precisamente en un fallo no hay que omitir la limpieza)
  ├─ Registrar en el log con Write text to file (Append)
  ├─ Notificar al administrador con Send an email (V2)
  └─ Elegir entre "reanudar desde el final del bloque" o "detener la ejecución del flujo"

Conviene tener presentes varios puntos.

• El manejo de errores de una acción individual tiene prioridad sobre el manejo por bloque, así que conviene repartir responsabilidades: configuración individual cuando se quiere cambiar el comportamiento solo de una acción concreta, y agrupar el resto bajo On Block Error.¹
• Con «Retry action if an error occurs» se puede reintentar automáticamente, un número de veces y con un intervalo determinados, ante errores temporales (como retrasos de red o bloqueos de archivo). Si se marca como reintentable todo tipo de error, se pierde tiempo innecesariamente, así que conviene distinguir entre los errores que merece la pena reintentar y los que no (como una inconsistencia de datos).¹
• Si dentro del controlador de errores se quiere consultar el contenido del error inmediatamente anterior, hay que colocar explícitamente la acción Get last error. Es una acción que devuelve una variable con seis propiedades del error producido (nombre, lugar, acción implicada, subflujo al que pertenece, detalle y mensaje); no se genera automáticamente como una variable implícita. Para evitar reutilizar por error el mismo valor de error más tarde, es más seguro limpiarlo después de obtenerlo con la opción «Clear error».¹
• El log no debe limitarse a «éxito/fallo»: conviene dejar también el número de elementos procesados, el nombre del archivo afectado y el mensaje de error. Las únicas pistas disponibles después para averiguar «por qué se detuvo» están en el log.
• Como acción posterior al bloque, hay que elegir explícitamente entre «reanudar desde el final del bloque» o «detener la ejecución del flujo». Detener con la instancia de Excel todavía abierta puede provocar incidentes, como que el proceso quede residual en la siguiente ejecución, así que precisamente en un error hay que tener presente la limpieza (cerrar la instancia).¹³

Para quien esté acostumbrado a try/catch/finally de PowerShell, resulta más fácil de diseñar si se piensa en el «bloque» de On Block Error como el try, el controlador de errores como el catch y la secuencia de limpieza como algo cercano al finally.

7. Estabilizar la automatización de UI

La causa principal de inestabilidad en los flujos de escritorio suele estar, en la mayoría de los casos, en el «método de identificación de los elementos de UI (el selector)».

• Por defecto, el selector de elementos de UI registra los elementos de pantalla como un selector (una combinación de atributos). Si incluye atributos frágiles ante una actualización de la aplicación o un cambio en el contenido mostrado (como un índice secuencial o un ID dinámico), el flujo se rompe aunque el aspecto visual sea el mismo.¹⁴
• Cambiar los atributos cuyo valor varía de Equals a Contains o a una expresión regular, y convertir en variable los valores que dependen del resultado de una acción anterior, produce un selector más dinámico y resistente a romperse.¹⁴
• Configurar varios selectores permite que, si el primero falla, se recurra automáticamente al siguiente. Para las operaciones importantes, tener un selector de reserva mejora la estabilidad.¹⁴
• Si un selector se rompe, la función Repair selector puede generar automáticamente candidatos de reparación. Vale la pena probarla antes de reconstruirlo manualmente desde cero.¹⁴
• Las transiciones de pantalla y el inicio de aplicaciones tienen un desfase de tiempo. En lugar de depender solo de un Wait fijo, conviene combinar acciones de espera condicional como «esperar a que aparezca la ventana» o «esperar hasta que se encuentre el elemento de UI», y configurar también un reintento automático para cuando no se encuentre el elemento.¹⁵
• Para los objetivos de automatización que definitivamente no se estabilizan (pantallas virtualizadas, pantallas cuyo diseño cambia con frecuencia, etc.), no hay que aferrarse a la operación por UI: conviene comprobar primero si existe una forma de integración más estable, como una API, el intercambio de archivos o el acceso a una base de datos.

Hacer funcionar la automatización de UI la primera vez no es, en sí, difícil. Que siga funcionando sin romperse seis meses después depende casi por completo de cómo esté construido el selector.

8. Manejar las credenciales de forma segura

En la automatización de procesos empresariales, el punto donde más incidentes suelen producirse es el manejo de las credenciales (contraseñas, claves de API, cadenas de conexión, etc.).

• Evite escribir la contraseña o la información de conexión directamente como valor en una variable de entrada del flujo. Con la acción Get credential se puede obtener la credencial de forma segura desde las «credenciales de Power Automate», que usan Azure Key Vault o CyberArk como almacén de secretos subyacente; el valor obtenido queda marcado como información confidencial y no aparece en el log de ejecución del flujo.¹⁶¹⁷
• Si se usa Azure Key Vault como almacén de secretos, la información de conexión al Key Vault se puede gestionar de forma centralizada desde Power Automate, de modo que las credenciales no quedan dispersas flujo por flujo.¹⁷
• Para la ejecución desatendida, prepare una cuenta dedicada con el alcance de uso reducido al mínimo necesario, y evite compartirla con la cuenta que una persona usa a diario. Cuanto más amplios sean los permisos de la cuenta, mayor será el alcance del impacto de un fallo o un error de configuración en el flujo.
• Si se avanza en las pruebas dejando la contraseña en texto plano en una variable de entrada «temporalmente, para que funcione», es habitual que acabe quedando así también en producción. Es más seguro acostumbrarse a usar la acción Get credential ya desde la fase de pruebas.

9. Gobernanza y operación

Cuando aumentan los flujos creados a nivel individual o de equipo, el siguiente paso es la gobernanza a nivel de organización.

• Las políticas de prevención de pérdida de datos (DLP) son un mecanismo que clasifica los conectores utilizables en flujos y apps en categorías como «solo datos empresariales», «no apto para datos empresariales» o «bloqueado», e impide combinar en un mismo flujo un conector de datos empresariales con uno no apto para datos empresariales. Es la primera gobernanza que conviene establecer para evitar que los datos de la organización se filtren de forma involuntaria hacia servicios externos.¹⁸
• Las acciones de flujo de escritorio también se pueden clasificar y bloquear dentro del mismo marco de políticas DLP, pero esto no está activado por defecto. Es necesario activar una vez «Show desktop flow actions in DLP policies» en la configuración del inquilino del Centro de administración de Power Platform, y este ajuste no se puede revertir después. Incluso una vez activado, solo quedan bajo control los módulos y acciones clasificados explícitamente en la política, así que hay que tener en cuenta que «haber creado una política DLP» no implica necesariamente que todo el flujo de escritorio esté bajo control.²
• Las máquinas para ejecución desatendida se gestionan agrupadas en grupos de máquinas, dejando claro qué flujo se ejecuta en cuál máquina.
• Decida de antemano dónde consultar el historial de ejecución. Para un flujo en la nube individual, iniciando sesión en Power Automate y yendo a «Mis flujos» → el flujo en cuestión → «Historial de ejecución» en la página de detalles, al seleccionar una ejecución fallida se puede ver en qué acción falló y el detalle del error. En «Analytics», en el menú superior de esa misma página de detalles, se ve la tasa de éxito/fallo y el historial de ejecución de los últimos 30 días. Cuando se quiere ver sin omisiones los fallos de todo el inquilino o de todo el entorno, lo más exhaustivo es Monitor en el Centro de administración de Power Platform.¹⁹²⁰ Además, como aparecen fallos en cascada (acciones posteriores que se marcan como fallidas por arrastre de una acción anterior que falló primero), la norma es revisar en el historial de ejecución cuál fue “la primera acción que falló”.¹⁹
• Conviene conocer los límites de la notificación de fallo estándar y añadir una propia. Power Automate envía dos tipos de correo ante el fallo de un flujo en la nube. Uno es la alerta de fallo por ejecución, que se envía al propietario y a los copropietarios del flujo solo cuando se puede determinar que la causa es “un motivo con una solución conocida”, como una desconexión o una limitación por throttling. Además, esto requiere que esté activado en la configuración del flujo, y una vez enviada para un flujo, entra un periodo de enfriamiento de 28 días. El otro es un resumen semanal, que llega agrupando también los fallos generales que no generaron alerta.¹⁹ En otras palabras, no se puede cubrir «cada vez, de inmediato, al responsable» solo con las funciones estándar. Incorpore como parte del propio flujo, desde el controlador de errores del capítulo 6, un proceso que notifique al administrador por correo o por Teams.
• Cuando se quiere manejar desde un flujo en la nube recursos locales a los que no se puede acceder directamente desde la nube, como una base de datos o un recurso compartido de archivos en la red interna, se usa la puerta de enlace de datos local. La puerta de enlace no requiere abrir puertos de entrada desde el lado de la nube y hace de puente de forma segura solo con una conexión de salida.²¹
• Separar los entornos de pruebas y de producción, y mantener los flujos de escritorio y la información de conexión diferenciados por entorno, evita que un cambio hecho durante las pruebas afecte al flujo de producción.

10. Los límites de Power Automate y los criterios para escalar

Power Automate es potente, pero no es una solución universal. En las siguientes situaciones conviene plantearse el cambio a PowerShell o a una aplicación .NET.

Cuando se percibe que «lo que se construyó en Power Automate ha crecido y se ha vuelto demasiado complejo», en lugar de seguir ampliando el flujo a la fuerza, suele resultar más fácil de mantener a la larga extraer el procesamiento central a .NET o PowerShell, y dejar que Power Automate se dedique solo al disparador y a la notificación. Un ejemplo práctico de investigación de logs y automatización de archivado con PowerShell se presenta también en el artículo «Aplicaciones de scripts de PowerShell — Automatizar de forma segura la investigación de logs, el archivado y la generación de informes».

11. Resumen

Power Automate resulta sorprendentemente sencillo hasta el primer paso. Pero esa misma facilidad tiene un reverso: «incluso si se recorta el diseño, funciona igualmente, al menos al principio». Que un flujo llevado a producción se pueda mantener a largo plazo depende, casi por completo, de cuántas decisiones poco vistosas se hayan resuelto desde el inicio.

Qué usar, si el flujo en la nube o el de escritorio, y qué procesos conviene dejar en manos de PowerShell o .NET: resolver esta distinción desde el principio reduce considerablemente el retrabajo posterior. El manejo de errores, los selectores de UI, las credenciales, las licencias y las políticas DLP salen, en todos los casos, abrumadoramente más baratos si se incorporan «desde el inicio» que si se «corrigen después de que ya funciona». Y saber decidir, cuando el flujo crece y se complica, si conviene derivar el procesamiento a .NET o PowerShell en lugar de ampliarlo a la fuerza, también determina si se podrá seguir usando a largo plazo.

Entre «un flujo que funciona, sin más» y «un flujo en el que se puede confiar con tranquilidad» hay toda esta diferencia de diseño. Cuanto más involucra la automatización a sistemas empresariales existentes o a activos de Excel/VBA, más determina la decisión de diseño inicial el coste de mantenimiento a largo plazo.

Artículos relacionados

• Qué es VBA: limitaciones, futuro, cuándo conviene reemplazarlo y patrones de migración realistas
• Aplicaciones de scripts de PowerShell — Automatizar de forma segura la investigación de logs, el archivado y la generación de informes
• Cómo generar informes de Excel: COM, Open XML y plantillas

Áreas de consultoría relacionadas

En KomuraSoft LLC atendemos consultas sobre la automatización y modernización gradual que conserva los activos empresariales existentes de Excel, VBA y Windows, así como revisiones de diseño de plataformas de automatización que incluyen Power Automate.

• Aprovechamiento de activos existentes y apoyo a la migración
• 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.

¿Cómo se elige entre un flujo en la nube y un flujo de escritorio?

El flujo en la nube es un mecanismo que conecta servicios en la nube entre sí a través de conectores, y es adecuado para flujos de aprobación, notificaciones, integración con SaaS y procesos en torno a Microsoft 365. El flujo de escritorio es un RPA que opera directamente aplicaciones y pantallas de Windows, y es una opción realista cuando hay que manejar la pantalla de un sistema empresarial antiguo sin API o de una aplicación Win32. Al recibir una consulta, el panorama se aclara bastante si se empieza por separar si se trata de conectar servicios en la nube entre sí o de operar una pantalla.

¿Cuándo conviene usar Power Automate y cuándo PowerShell?

Si lo único que se busca es automatizar tareas repetitivas en el PC, cuando no es imprescindible hacer clic o escribir en pantallas, PowerShell suele ser más fácil de mantener y se presta mejor al control de versiones con Git. Operar mediante UI un sistema que ya cuenta con una API es, en realidad, más estable si se llama directamente a la API desde PowerShell o .NET. El procesamiento de datos del orden de cientos de miles de filas, la lógica compleja que requiere pruebas automatizadas y los procesos residentes de alta frecuencia también son más apropiados para PowerShell o .NET. Cuando el flujo se vuelve demasiado complejo, extraer el procesamiento central y dejar que Power Automate se dedique solo al disparador y a la notificación resulta más fácil de mantener.

¿Qué licencia se necesita para la ejecución desatendida de Power Automate?

La ejecución desatendida necesita una licencia distinta de la de la ejecución asistida: se usa la licencia Power Automate Process, que se vincula al flujo o a la máquina. El antiguo complemento de ejecución desatendida se considera obsoleto y ha sido reemplazado por la licencia Process. Además, la licencia Process por sí sola no sustituye a la licencia de usuario: el registro de la máquina requiere un usuario con licencia Power Automate Premium. Y como en Windows 10/11 la ejecución desatendida falla si queda bloqueada la sesión de cualquier usuario, es necesario que todos cierren sesión.

¿Cuál es la causa de que la automatización de UI del flujo de escritorio se vuelva inestable?

La causa principal suele estar en el método de identificación de los elementos de UI, es decir, el selector. Si incluye atributos frágiles ante el cambio, como un índice secuencial o un ID dinámico, el flujo se rompe aunque el aspecto visual sea el mismo. Como medida, hay que cambiar a Contains o a una expresión regular los atributos cuyo valor varía en lugar de usar Equals, configurar varios selectores para que haya fallback entre ellos y, si se rompe, generar candidatos de reparación con la función Repair selector. También es importante combinar acciones de espera condicional en lugar de depender solo de un Wait fijo. Que el flujo siga funcionando sin romperse seis meses después depende casi por completo de cómo esté construido el selector.

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.