Issue
When scheduling a botflow or running it manually from RPA Central, and the Bot is in Ready status but the botflow goes into Queued status, the reason is usually because the user that is attached to the bot being used for the botflow is inactive.
A bot is created by using the User Account Name and the machine they are on. With Windows 10 only one user can be active at a time. If using a different server environment, there may be an option of 2 or more at a time.
Either way, when the botflow is scheduled, if the user that is attached to that bot is not active, it will go into Queued status and not run until that user logs in. At that point, once the user is completely logged in, refresh the Instances page, and the status will change to Running status (you may need to refresh the page a few times if the user’s machine is still loading).
Error Code
Queued Status in Botflow Screen in RPA Central
Resolution
With 2 bots and 2 users you will see this in RPA Central if you click the Bots menu on the left:
As an example, when logged in as the user attached to the RPAC Bot above and a botflow is scheduled that is attached to the user of the Service Bot above, and in the Task Manager that second user is listed as inactive, to avoid having the botflow go into queued status, the choices are to 1) change the bot as shown below or 2) make that other user active.
Additional Information
When assigning multiple bots to a botflow, and the bot assigned is in ready status and the user is active, the botflow will run the botflow. If the bot or user is not ready, the botflow will remain in Queued status until they are ready again.
RPA Central keeps an internal list of all the bots that are in ready status with the user showing as active in the order that this happens.
For example: Two users, P1 and P2, are assigned to the botflow. Both of their bots are also assigned to the botflow.
P1 - logs into their machine at 8:00 am
P2 - logs into their machine at 8:01 am
P2 asks RPAC to run the botflow. RPAC will use P1's bot since that user was ready first.
If P1 has a botflow with only their bot assigned to it and they now ask RPAC to run their botflow, the botflow will remain in queued status until the first botflow is complete and P1s bot is back in ready status.
