We have a process that reads queue items and enters data into a web application. So it iterates through items and processes them, like a normal automation.
When we run it from orchestrator it will throw a business exception on the first record (correctly, we are checking if an item has already been entered), and then it goes on to the second item and throws an application exception because it cannot find the UI item - the browser has been closed.
However, when this is run from Orchestrator and we log into the server to “watch” the application, this behavior does not happen - the browser does not close.
We are baffled as to what the difference is between being logged in watching and running it and not being logged in (using of course the same ID). The logs show us only that the UI element is not there AND that the browser is not open.
I just wanted to report back what the error turned out to be.
There is a setting in Orchestrator (didn’t know about it) on screen resolution. When accessed without logging in the resolution in Orchestrator caused the program to throw an error. When logged in, the RDP session’s resolution overrode the setting in orchestrator, and thus everything worked.
I was about to mention what you discovered. The Login to Console is quite an important setting for VDI or RDP sessions.
What essential happened was your robot was stuck at the login screen and programs can be opened by robots when in lock screen but the moment it has to interact with the element of the application, it will fail.