Selectores robustos y tiempos de espera en Power Automate Desktop

Cuando una automatización de interfaz creada con Power Automate Desktop (PAD) falla de repente con “Failed to get UI element” tras semanas en producción, casi nunca es casualidad. Normalmente algo ha cambiado en segundo plano que el selector ya no encuentra: una actualización de la aplicación, una resolución de pantalla distinta, una ventana que ahora tarda un segundo más en abrirse. Precisamente en estos dos factores, selectores robustos y tiempos de espera limpios, se decide si un flujo funciona de forma estable durante meses en modo desatendido o hay que repararlo manualmente cada pocos días.

Esta guía te muestra cómo se construyen los selectores en PAD, qué operadores y variables los hacen dinámicos, y cómo sustituir pausas fijas por una sincronización real usando las acciones Wait adecuadas. Al final encontrarás una checklist para proteger tus flujos existentes frente a las causas de fallo más habituales.

Por qué se rompen los selectores

Un selector en Power Automate Desktop describe exactamente dónde se encuentra un elemento de interfaz en la jerarquía de una aplicación o una página web. Según Microsoft, los selectores se crean cuando PAD captura propiedades como el nombre, la clase o el ID de automatización, además de la posición del elemento en la estructura de la interfaz. Precisamente esa captura es lo que hace que los selectores sean sensibles a los cambios. Microsoft menciona en la guía de solución de problemas de flujos de escritorio desatendidos entre otros los siguientes factores, que pueden invalidar un selector que antes funcionaba:

• La resolución de pantalla y el escalado DPI
• Las actualizaciones de la aplicación o los cambios en la interfaz de usuario
• La versión del sistema operativo
• El tamaño o el modo de la ventana, por ejemplo maximizada frente a modo ventana
• El estado de un elemento, habilitado o deshabilitado
• Los permisos de usuario, ya que una aplicación puede cargarse de forma distinta según el perfil

Quien sabe en qué puntos suele romperse un selector puede construirlo desde el principio para que resista esas variaciones, en lugar de reaccionar solo tras el primer fallo.

La estructura de un selector: niveles, atributos, operadores

Un selector se compone de varios niveles encadenados con el carácter >. Cada nivel describe un elemento con sus atributos en la forma element[Attribut1="Wert1"][Attribut2="Wert2"]. Un ejemplo sencillo de la documentación sobre cómo crear una selección personalizada muestra una ventana de editor: :desktop > window[Name="Notizen.txt - Editor"][Process="Notepad"]. El primer nivel siempre empieza con el elemento raíz :desktop, y cada nivel siguiente es hijo del anterior.

Operadores en lugar de valores fijos

El operador predeterminado Igual busca un valor exacto y fijo. Esto funciona de forma fiable en aplicaciones estáticas, pero pronto se convierte en un problema en cuanto los títulos de ventana cambian dinámicamente, por ejemplo por un nombre de archivo o una marca de tiempo en el título. Power Automate ofrece para ello otros cinco operadores:

• Distinto de, comprueba cualquier valor excepto uno concreto
• Contiene, encuentra elementos que no tienen un patrón fijo pero incluyen una palabra clave concreta
• Empieza por, comprueba el inicio de un valor
• Termina en, comprueba el final de un valor
• Coincidencia de expresión regular, comprueba frente a un patrón propio basado en el motor de expresiones regulares de .NET

Un título de ventana como “Notizen.txt - Editor (2)” se puede capturar de forma mucho más robusta con Empieza por que con Igual, porque el número entre paréntesis al final puede variar sin que el selector se rompa.

Variables para valores dinámicos

Si el valor de un atributo depende de una acción anterior, por ejemplo un nombre de archivo que solo se conoce en tiempo de ejecución, puedes insertar en el selector una variable con notación de porcentaje, como :desktop > window[Name="%WindowName%"][Process="Notepad"]. Así el selector sigue siendo válido aunque el valor esperado cambie de una ejecución a otra.

Usar varios selectores y un mecanismo de respaldo

Un mismo elemento de interfaz puede tener varios selectores en PAD. Si el primero falla, Power Automate pasa automáticamente al siguiente en el orden definido, sin ningún paso adicional que programar en tu flujo. Con el botón Selección con nueva captura o copiando un selector existente, puedes crear variantes adicionales, por ejemplo una con Igual para el caso normal y otra con Contiene o Regex como nivel de respaldo.

Para interfaces especialmente inestables, como sesiones de terminal o aplicaciones heredadas sin una jerarquía de interfaz limpia, Microsoft recomienda en la misma guía además el respaldo por imagen, en el que PAD recurre al reconocimiento de imágenes en lugar de a los atributos de interfaz cuando ya no funciona ningún selector normal.

Tiempos de espera reales en lugar de pausas fijas

Las acciones “Wait” fijas con un número de segundos son un motivo frecuente de que los flujos vayan innecesariamente lentos o accedan a un elemento demasiado pronto. Power Automate Desktop ofrece para ello acciones de sincronización dedicadas, que esperan al estado real de la aplicación en lugar de dejar pasar ciegamente un intervalo de tiempo.

• Esperar ventana pausa la ejecución hasta que una ventana concreta se abre, se cierra, obtiene el foco o lo pierde. La búsqueda puede hacerse mediante un elemento de interfaz, mediante instancia o handle, o mediante título y clase.
• Esperar el contenido de la ventana pausa hasta que un texto concreto o un elemento de interfaz aparece o desaparece en una ventana, opcionalmente incluyendo la comprobación de si el elemento está habilitado o deshabilitado. Esta es exactamente la acción que Microsoft recomienda en la referencia de acciones de automatización de la interfaz de usuario, cuando un elemento de interfaz aún no está disponible en el momento de la ejecución.
• Esperar imagen espera hasta que una imagen aparece o desaparece en la pantalla o en la ventana en primer plano, incluyendo una tolerancia ajustable y la elección entre coincidencia de imagen simple y avanzada.

Las tres acciones se pueden configurar para que fallen con un error de tiempo de espera agotado tras transcurrir un tiempo definido, en lugar de esperar indefinidamente. Esto es importante para los flujos desatendidos, para que una ventana bloqueada no paralice toda la ejecución, sino que pase de forma controlada al manejo de errores.

Probar y reparar selectores

Antes de que un flujo pase a funcionamiento desatendido, merece la pena probar cada selector crítico directamente en el Selector Builder. Si un selector se rompe de todos modos, la función «Reparar selector» ofrece una ayuda rápida: recapturas el elemento con Ctrl+clic izquierdo, PAD compara la estructura antigua con la nueva y propone una selección reparada, que aún puedes revisar antes de aceptarla. Si un selector contiene variables, la reparación automática no funciona según Microsoft, y solo queda el ajuste manual en el editor de texto del Selector Builder.

Checklist para flujos estables en modo desatendido

Para los flujos que van a funcionar de forma permanente sin supervisión, Microsoft resume varias recomendaciones que han demostrado su valor en la práctica:

• Guardar varios selectores por elemento para que un respaldo pueda entrar en acción
• Construir selectores con atributos estáticos y capturar las partes dinámicas mediante operadores o variables
• Usar el respaldo por imagen allí donde los atributos de interfaz no sean lo bastante fiables
• Configurar una política de reintentos en el manejo de errores de cada acción crítica
• Elegir el tipo de acción adecuado, automatización web para elementos web, automatización de interfaz para elementos de escritorio
• Asegurarte de que la aplicación arranca en el mismo modo de ventana en modo desatendido que en la prueba supervisada
• Recapturar y probar el selector directamente en la máquina desatendida

Con esta combinación de selectores robustos y condiciones de espera reales, un flujo se queda en el vacío mucho menos a menudo. Mantienes el control del proceso, porque cada acción solo arranca cuando la aplicación está realmente lista para ella, en lugar de lanzarse tras un tiempo de espera estimado y confiar en la suerte. Quien use Power Automate Desktop de forma productiva a mayor escala debería planificar estas medidas de estabilidad desde el principio, por ejemplo en el marco de proyectos de automatización acompañados, en lugar de incorporarlas solo después de los primeros fallos nocturnos.

Preguntas frecuentes

¿Por qué no basta con una simple acción “Wait” con un número fijo de segundos?

Un tiempo de espera fijo solo estima cuánto necesita una aplicación, pero no reacciona a su estado real. Si la aplicación es más rápida, el flujo pierde tiempo innecesariamente; si es más lenta, por ejemplo por carga de red o un servidor lento, la siguiente acción intenta acceder a un elemento que todavía no está ahí. Acciones como Esperar el contenido de la ventana o Esperar ventana comprueban en cambio el estado real de la aplicación y solo continúan cuando la condición realmente se cumple.

¿Cuál es la diferencia entre “Esperar ventana” y “Esperar el contenido de la ventana”?

Esperar ventana se refiere a la ventana como conjunto, es decir si se abre, se cierra, obtiene el foco o lo pierde. Esperar el contenido de la ventana va un nivel más allá y comprueba si, dentro de una ventana ya abierta, aparece, desaparece o cambia su estado habilitado o deshabilitado un texto concreto o un elemento de interfaz concreto. En la práctica, a menudo combinas ambas: primero esperar la ventana, después el contenido concreto.

¿Cuántos selectores debería crear por elemento de interfaz?

No hay un número fijo, pero Microsoft recomienda explícitamente guardar varios selectores por elemento para que entre en acción un respaldo si el primero falla. En la práctica, con dos o tres variantes basta para la mayoría de los elementos, por ejemplo una con Igual para el caso normal, una con Contiene o Regex como respaldo, y para interfaces especialmente inestables, además un respaldo por imagen.

¿Puedo hacer que un selector con variables se repare automáticamente?

No. Según la documentación de Microsoft, la función de reparación automática no funciona con selectores que contienen una o más variables. En ese caso debes sustituir temporalmente las variables por valores estáticos para usar la reparación, o ajustar el selector directamente a mano en el editor de texto del Selector Builder.

¿Qué hago si un selector sigue rompiéndose a pesar de la reparación y el respaldo?

Si ni siquiera un selector reparado con varios niveles de respaldo funciona de forma estable, suele ayudar, según Microsoft, cambiar al respaldo por imagen o a la automatización de superficie con acciones de ratón, teclado y OCR, especialmente en aplicaciones sin una jerarquía de interfaz limpia, por ejemplo en entornos de escritorio virtual. Además, merece la pena examinar la causa subyacente: a menudo se debe a una diferencia de resolución de pantalla, escalado DPI o modo de ventana entre el entorno de desarrollo y la máquina de destino desatendida.