A Robot is an execution host that runs processes built in UiPath Studio.

The Robots page enables you to add robots, edit them, view their status and license state, change the environment(s) they are assigned to, and the runtime settings. Additionally, you can display the logs generated by a single Robot.

📘

Note:

When a Robot is busy (executing a process), you cannot edit the following information:
Username
Machine
Type

Robots can automatically download processes, and execute them under custom settings. You can configure automatic process downloading, logging level, font smoothing, and resolution in the Settings tab while creating or editing a robot.

Robot Authentication

There are two ways to authenticate your Robot as specified at Robot creation either on the Create a New Standard Robot window or on the Create a New Floating Robot window:

• Using Username/Password Credentials - This is the default method.
• Using SmartCard Authentication - Select the The password represents a SmartCard Pin option to enable this authentication method. This option is only available if the Features.SmartCardAuthentication.Enabled parameter in web.config is set to True.

📘

Note

Attended Robots do not support SmartCard authentication.

Robot Licensing Status

The licensing status of Attended and Development Robots is displayed in the Username column, as in the screenshot below:

• A Robot is marked with a green icon if it had acquired a license.
• A Robot is marked with orange if it is unlicensed.
  If the machine the Robot is installed on is offline or the UiPath Robot service is stopped, nothing is displayed.

For more information about licensing, click here.

Environments

A grouping of Robots in a Classic folder is called an environment and it enables you to execute the same package on multiple Robots simultaneously.

📘

Important!

If you have multiple Robots on the same machine, it is recommended that you group them in the same environment and Orchestrator tenant. Otherwise, some errors might occur when deploying different versions of the same process.

For more information about environments, click here.

Types of Robots

According to the Management Type

• Manually Managed - Robots in classic folders where Robot management is done manually. This includes creation, deletion, adding a Robot to an environment such that it's able to execute processes from that environment, removing a Robot from the environment to restrict it from executing the processes. All these actions are specific to one classic folder. If you want your Robot to have access to processes found in a different classic folder, you are required to delete it from the first folder, and provision it in the new one.
• Automatically Managed - Robots in modern folders where Robot management is done automatically. In this scenario, the user entity is configured to have a Robot automatically provisioned. The license and execution settings of the Robot are configured at user definition as well. The moment the user opens his Robot Tray, the Robot gets automatically provisioned in Orchestrator according to those settings. The Robot has access to whatever processes exist in the folders the user has access to.
  Robot management can be made for directory users or directory groups as well. The automatic Robot provisioning setting for a directory group that's added to Orchestrator is inherited by any user that is a member of that AD group.

According to the Robot/Machine Interaction

• Standard Robot - works on a single Standard Machine only, namely the one defined when creating it. This is ideal for the scenario in which a user always works on the same machine.
• Floating Robot - works on any machine defined in Orchestrator, be it Standard or Template, as the machine name is not relevant when creating it. Only Attended and Development Robots can be floating, and as such, they become licensed automatically when you open the Robot tray. These types of Robots only work with Active Directory users and are useful if the machine you want to add a Robot to has a different name each time it is spawned, such as for Non-Persistent VDIs. Same goes for hotseat environments, where different people are working in shifts on the same computer.

Example

Let's say you have an environment with 8 users working on non-persistent virtual desktops. Machine allocation is done randomly, so one user can be allocated any of the available machines in the VDI.

• In the standard scenario, you would have to define a Robot for each user/machine combination. For a VDI with 8 machines that means 64 Robots.
• In the floating scenario, you only need to define one machine template and 8 Floating Robots (one for each user). The template persists across your entire VDI such that each of the users can connect to their Robots using one key, the Machine Template key.

According to the Use Case

• Attended - works on the same workstation as a human user and is usually triggered by the user through their actions (user events). You cannot start processes from Orchestrator on this type of Robots, and they cannot run under a locked screen. They can be started only from the Robot tray or from the Command Prompt. Attended Robots should only run under human supervision.
• Unattended - runs unattended in virtual environments and can automate any number of processes. On top of the Attended Robot capabilities, this Robot is responsible for remote execution, monitoring, scheduling and providing support for work queues.
• NonProduction - retains all the features of the Unattended Robot, but it should be used only for development and testing purposes.
• Studio / StudioX - has the features of an Unattended Robot, but it should only be used to connect your Studio to Orchestrator for development purposes.

All types of Robots can run in debug in Studio.

For more information, see the UiPath Robot Documentation Portal.

About High-Density Robots

Regardless of the Windows version a machine is running on, if you have multiple users on it, you can register a Robot on each of the users. This feature is called High-Density Robots and ensures a full utilization of each machine at your disposal at its maximum potential. It can be applied to all types of Robots (Attended, Unattended and NonProduction).

The High-Density environment has the following advantages:

• On a machine with a Windows Server (2008 R2 or 2012 R2 or 2016) operating system:
  • you can run the same process with all Robots in the same time;
  • you can run different processes with all Robots in the same time.

To set up High-Density Robots on a Windows Server machine, please see the Setting Up Windows Server for High-Density Robots chapter.

📘

Note:

On the same machine, you have to connect all users as Robots to Orchestrator, all with the same Machine Name and Key.

If you register a new Robot to Orchestrator on a machine while the UiPath Robot service is running, you have to restart the service.

If the username and/or password filled in when deploying the Robot to Orchestrator do not correspond to the Windows credentials for the specified user, the first job you run is faulted and a "Logon failure" message is displayed in the Job Details window.