We have multiple processes built, which start their jobs based on timed triggers. We have more jobs than robots so once in a while the jobs are pending to start. No problem so far.
Our unattended windows environment starts by the UiPath Orchestrator triggering a windows login, then runs the job, and after completion logs off the windows session. Still no problem.
The problem occurs in the next job. Dynamic allocation favours the first available Robot according to a fixed sequence. (The order of creation it seems). This often means that Bot1 runs a process and completes it, and once done immediately starts the next pending job. And this is where the problems start.
The end process reports to the orchestrator that the job is completed and the Robot available, while in fact this robot is still completing log-off activities and session ending on our workspace server. The next immediate start of the new job on this machine results in an ‘access denied’ error, failing the eintire job, simply because windows wasn’t available yet.
Queueitems have retry capabilities, but entire jobs don’t.
Double scheduling of jobs can cause operational issues so this is no option, and dynamic allocation of jobs on Robots is a requirement.
Does anybody have any advise on how to solve this synchronisation between orchestrator and workspace status?