La aplicación cambia el formulario y el robot sigue encontrando un botón llamado Guardar. Sin embargo, ahora ese botón pertenece a otro panel o el formulario incluye un campo nuevo. El selector funciona y la automatización puede ejecutar una acción equivocada.
Detectar cambios de interfaz exige verificar el estado de la pantalla, la identidad del elemento y el efecto de la acción. Localizar un control es solo una parte de esa comprobación.
Inventaría las pantallas que sostienen el proceso
Identifica los puntos donde el robot lee, decide o escribe. Para cada uno, conserva qué pantalla espera, qué datos debe reconocer y qué acción puede ejecutar.
Distingue elementos estables y dinámicos. Un identificador que cambia en cada sesión puede servir para una captura aislada y fallar al día siguiente. Un texto demasiado general puede localizar varios controles.
La guía de selectores personalizados de Power Automate describe cómo atributos y jerarquía delimitan el elemento. También permite alternativas de selección; cada alternativa necesita validarse para evitar que amplíe la búsqueda hasta un control incorrecto.
Paso 1. Verifica el estado antes de escribir
Comprueba señales del contexto: título o sección, entidad abierta, campos esperados y ausencia de una pantalla de error o autenticación. El robot no debería escribir datos solo porque encontró una caja de texto.
En un ejemplo ficticio de actualización de catálogo, confirma la referencia del producto antes de modificar su descripción. El mismo formulario puede mostrar productos distintos sin cambiar la estructura de la pantalla.
Si aparece una ventana desconocida, conserva evidencia mínima y detén la parte que produce efectos. Pulsar sucesivamente botones para ‘salir del bloqueo’ puede confirmar una acción que el flujo no entiende.
Paso 2. Comprueba unicidad y significado del selector
Un selector debe localizar el control previsto en el contexto previsto. Prueba que no encuentre otro con atributos parecidos en una tabla, modal o panel lateral.
Eliminar atributos de un selector puede hacerlo más tolerante a cambios y también menos preciso. Valida ambas consecuencias. Un selector que vuelve a encontrar algo no está necesariamente reparado.
Evita depender de coordenadas cuando existe una forma más estable de reconocer el elemento. Si el entorno obliga a utilizar posición o imagen, documenta las condiciones que necesita: resolución, escala, idioma y disposición de la ventana.
Paso 3. Separa espera de cambio estructural
Una pantalla puede tardar en cargar sin haber cambiado. Espera una condición verificable con un límite, como la presencia del panel y su referencia, en lugar de añadir pausas arbitrarias a todos los pasos.
Cuando se supera el límite, registra qué condición faltaba. No conviertas todos los fallos en un reintento del proceso completo. Si una acción ya pudo haberse ejecutado, aplica el diagnóstico de guardado incierto.
El objetivo es distinguir lentitud, pérdida de sesión, modificación de interfaz y resultado remoto no confirmado. Esas situaciones requieren recuperaciones diferentes.
Paso 4. Prepara una muestra de regresión
| Caso | Comprobación que debe pasar |
|---|---|
| Formulario habitual | Elementos correctos y efecto esperado |
| Campo opcional visible | La navegación mantiene su significado |
| Tabla con más filas | El selector conserva la entidad objetivo |
| Modal superpuesto | El robot no actúa sobre un control oculto o ajeno |
| Sesión caducada | Se reconoce la autenticación pendiente |
| Idioma o escala admitidos | Las condiciones del entorno siguen cumpliéndose |
| Pantalla desconocida | Detención controlada sin escritura adicional |
Utiliza datos de prueba y confirma el resultado en el destino. Una secuencia de clics sin excepciones técnicas no demuestra que los valores se guardaran donde correspondía.
Paso 5. Valida la reparación antes de reanudar
Guarda la versión del flujo y la evidencia del cambio de interfaz. Ejecuta la muestra sobre la nueva versión y comprueba tanto los casos corregidos como los que ya funcionaban.
Si se utiliza alguna capacidad de recuperación automática, limita sus acciones al alcance probado. No permitas que una interpretación incierta del control sustituya una autorización de negocio.
Revisa las tareas que quedaron pendientes durante la incidencia. Algunas pueden haberse completado parcialmente; reactivarlas como entradas nuevas puede duplicar efectos. La cola de excepciones debe conservar su etapa y referencia.
Paso 6. Registra las dependencias de la operación
Acuerda cómo se conocerán cambios previstos de la aplicación y qué prueba se ejecutará después. Incluye versiones del navegador o cliente cuando afecten al entorno del robot.
Observa fallos por pantalla y selector para localizar dónde se concentra la fragilidad. No uses esa observación para atribuir resultados de negocio que no se han medido.
Si estás manteniendo una automatización RPA, comparte con Nexeus Big Data las pantallas críticas y los cambios que suelen interrumpir el proceso. Con ese inventario se puede definir una regresión que compruebe acciones y resultados antes de devolver el robot a la operación.