Considerations for running automations
- Updated: 2025/03/19
Review the considerations listed in this topic when running automations.
- The status events or messages sent from Bot launcher to Node Manager is rate limited, and might vary in comparison to the status events shared with the Bot Agent runtime. During a crash, an error message describing the last line number that is displayed in the Control Room might not be same as seen on the Bot Agent runtime due to the rate limitation.
- As a Bot Creator, you can deploy an automation on your device or you can run the automation on a remote machine through RDP connection.
- If you are running automations on your local machine as a Bot Creator, enter only your username in the device log in credentials; no password is required. The username is required to confirm that the same user who logged in to the local device is deploying the automation. If you are using the Google Chrome plug-in and running automations on your local machine, your username is required.
- As a Bot Runner, you can either deploy the automation yourself or select a run-as user assigned by the administrator. You can run the automation either through your device or choose from the list of devices in a device pool. If you choose to override the default device, the automation will be executed on any available device in the device pool for each run-as user.
- You can preload packages on your local device to shorten the automation runtime.
The system supports running only one automation for each device at a given time. If a automation is already running on the device, you cannot deploy another automation on the device.
While a automation is running on a device, if you try to deploy another automation on the same device, the second automation is queued according to its type. After the deployment of the currently running automation is complete, the queued automation is automatically deployed on the same device.
- If you are running a automation from the Bot editor, closing the Control Room web browser will stop the bot run.
- Run-as user: A set of unattended Bot Runner users that a scheduler can select from to run a automation on a device. The run-as user can select an available device from the device pool to run the automation.
- If an automation is in progress, ensure that the associated run-as user is not disabled as this will stop the automation execution.
- When automations are queued for a Bot Runner user, automations with higher priority are deployed before automations with lower priority. However, if a bot with lower priority is already running, automations with higher priority are deployed after the automation with lower priority completes running.
- When you create the automation deployment using the Run bot now option, the automation is queued for execution. If the automation is deleted while it is queued for execution or while it is active, an error is displayed for that automation in the page.
- Attended Bot Runner, Bot Creator, and Citizen Developer users can run the bots using either the Run bot now option in the Bot editor or the shortcut key F5. However, unattended Bot Runner users can run their bots only using the Run bot now option.
- If a device pool is not selected, the deployment fails stating that no session is available.
- If the Override bot running device option is selected in the Device pool section and the default device is either in connected or disconnected state, it will go to other device in the device pool.
- If the Override bot running device option is not selected in the Device pool section and the default device is assigned to Bot Runner user, then the device must be in the connected state.
The following table explains the different scenarios where you should choose device pools against bot running devices for the run-as user.
Option | Scenario | Device pool | Default device | Result |
---|---|---|---|---|
Run bot now | Information security compliance where the user cannot log in to any other device | No | Yes | Automation is deployed on the default device of the user. |
Specialized application access restricted to a user | No | Yes | Automation is deployed on the default device of the user. | |
Schedule bot | Override bot running device option is selected | Yes | Yes | Automation is deployed on the default device of the user. |
Override bot running device option is not selected | Yes | Yes | Automation is deployed on the default device of the user. If the default
device is busy, the bot deploys on the available device in the device
pool. When the default device is down, configure the automation deployment queues. For more details, see Configure queue deployment. |
|
Information security compliance where the user cannot log in to any other device | No | Yes | Automation is deployed on the default device of the user. | |
Specialized application access restricted to a user | No | Yes | Automation is deployed on the default device of the user. | |
WLM (Run bot with queue) | Run on bot running devices option is selected | Yes | Yes | Automation is deployed on the default device of the user. |
Run on bot running devices option is not selected | Yes | Yes | Automation is deployed on the default device of the user. If default device is not available, the automation deploys on the available device in the device pool. | |
Automation Co-Pilot on the web | Run-as user with device pool assigned | Yes | No | Automation deploys on the available device in the device pool. |