El robot pulsa Guardar y espera un mensaje de confirmación. La aplicación se queda cargando, aparece otra ventana o se pierde la sesión. El paso falla, pero eso no demuestra que el registro no se haya guardado.
Repetir el bloque completo puede crear una segunda operación. Para recuperar este fallo, el flujo necesita distinguir el error de interacción de la situación real en el sistema destino.
Localiza el último efecto que podría haberse producido
Divide el flujo en preparación, envío y comprobación. Un fallo al localizar un campo antes de enviar tiene consecuencias diferentes de un fallo al leer la confirmación después de pulsar Guardar.
La gestión de errores de Power Automate para escritorio permite configurar acciones y bloques. Repetir un bloque vuelve a ejecutar sus pasos conforme a esa configuración; la herramienta no puede deducir por sí sola qué efecto de negocio quedó confirmado en otra aplicación.
Registra la etapa alcanzada y la referencia de la operación. No guardes capturas indiscriminadas con datos sensibles; conserva la evidencia mínima que permita investigar el caso con acceso adecuado.
Busca una referencia verificable en el destino
Antes de automatizar, identifica cómo reconocerás el resultado: un número de solicitud, una referencia externa admitida por el formulario o una combinación de campos cuya unicidad esté validada.
Si el sistema permite buscar por esa referencia, utiliza la consulta para reconciliar un resultado incierto. Una búsqueda por nombre aproximado puede confundir operaciones distintas. Tampoco basta con encontrar una fila: comprueba que corresponde al alcance y a los valores que se pretendían guardar.
La ausencia inmediata en una búsqueda no siempre demuestra que la escritura falló. La aplicación puede tardar en actualizar una lista o mostrar resultados paginados. Documenta qué vista ofrece confirmación fiable y qué espera admite el proceso.
Utiliza una decisión de recuperación explícita
| Evidencia obtenida | Interpretación | Siguiente acción |
|---|---|---|
| Fallo antes de enviar | No se inició el efecto en ese paso | Corregir la interacción y reanudar desde un punto definido |
| Operación encontrada y datos coincidentes | El resultado existe | Registrar su referencia y continuar |
| Operación encontrada con diferencias | Existe un estado que necesita revisión | Detener cambios y presentar la discrepancia |
| Confirmación fiable de no creación | Puede ser viable repetir | Aplicar la política de reintento autorizada |
| No se puede determinar el resultado | Estado incierto | Mantener pendiente para reconciliación |
Estas rutas deben adaptarse a las garantías del sistema concreto. Si no existe una forma fiable de consultar el efecto ni una protección contra duplicados, el caso incierto necesita intervención.
Reabrir la sesión no debe reiniciar el negocio
Recuperar una ventana, autenticarse de nuevo o volver a una pantalla inicial son acciones técnicas. No deberían crear automáticamente una nueva identidad de solicitud.
Conserva la relación entre el intento original y su recuperación. Si cambia el contenido, comprueba si la aprobación existente sigue siendo válida y si se está modificando una operación o creando otra.
La explicación del patrón Retry de Azure recuerda que un destino puede completar una acción y perder su respuesta. En una automatización visual, ese riesgo exige comprobar el resultado además de configurar pausas y número de intentos.
Prueba el instante posterior al clic
Ensaya el flujo con una confirmación retrasada, una sesión interrumpida y un mensaje superpuesto. Incluye un caso donde el registro se creó correctamente aunque el robot marque el paso como fallido.
Verifica cuántas operaciones existen después de recuperar cada caso. Que el robot termine en verde no es suficiente si dejó dos solicitudes en el destino.
Comprueba también que dos ejecuciones no procesan simultáneamente la misma entrada. La asignación del trabajo y las transiciones de estado deben impedir que una recuperación manual compita sin control con el robot.
Deja un procedimiento para el operador
La cola de excepciones debe mostrar referencia, etapa, evidencia y acciones permitidas. ‘Ejecutar de nuevo’ resulta insuficiente si antes hay que verificar un posible guardado.
Para revisar una automatización RPA, muestra a Nexeus Big Data cómo se identifica una operación en la aplicación destino y qué ocurre cuando falta su confirmación. Esa prueba permite diseñar una recuperación que conserve el control sobre los efectos, incluso cuando la interfaz falla.