UiPath Robot

The UiPath Robot Guide


The Robot is UiPath’s execution agent that enables you to run workflows built in Studio.

A Robot is installed as a Windows Service by default. As a result, the Robot can open Windows sessions (interactive or non-interactive), under the Local System account, and has all the rights of a Windows service.

Robots can also be installed in a user mode. For your Robot, this means that it has the exact same rights as the user under which it has been installed. This is also available for HD Robots.

Please note that packages downloaded by the Robot Service cannot be run by Robots in user mode. This is because the Robot Service downloads packages in the local system (not the local user), and the Robot in user mode does not have permissions for that folder. If this happens, it is recommended to delete all packages downloaded by the Robot Service, which are located in the %userprofile%\.nuget\packages folder.

Regardless of the mode in which you installed the Robot, it can still be connected to Orchestrator. Please note that closing the Robot tray does not close the UiPath Robot service.

Robots need to be connected to Orchestrator in order to execute processes or they have to be licensed locally.

The Robot is split into four components, each being dedicated to a particular task in your automations. The Robot components are:

  • Service (UiPath.Service.Host.exe):
    • Manages and monitors Windows sessions and acts as a proxy between Orchestrator and the execution hosts;
    • Trusted with and manages the credentials for Robots.
  • Executor (UiPath.Executor.exe):
    • Runs the given jobs under a Windows session (executes workflows);
    • Is aware of per-monitor DPI settings.
  • Agent (UiPath.Agent.exe, Robot Tray):
    • A WPF application which displays the available jobs in the system tray window;
    • Is a client of Service;
    • Can request to start or stop jobs and change settings.
  • Command Line (UiRobot.exe, Command line):
    • Is a client of Service;
    • A console application that can request to start jobs and waits for their output.

Having the Robot components split as explained above helps developers, support users, and computers easily run, identify, and track what each component is executing. Special behaviors can be configured per component this way, such as setting up different Firewall rules for the Executor and the Service.

The Executor is always aware of DPI settings per-monitor. As a result, workflows can be executed at any DPI, regardless of the configuration on the machine they were created on. Projects created in Studio 2018.2 are independent of browser zoom level. For apps that are DPI unaware or intentionally marked as unaware, you can choose to disable DPI.

Types of Robots

The license that was chosen dictates a Robot's capabilities, as follows:

  • Attended - operates on the same workstation as a human, to help the user accomplish daily tasks. It is usually triggered by user events. You cannot start a process 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 - run 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.
  • Development - has the features of an Unattended Robot, but it should be used only to connect your Studio to Orchestrator, for development purposes.

You are able to run debugging in Studio with all types of Robots.

For more information on licensing, please see the About Licensing.

Connecting a Robot to Orchestrator offers the following benefits:

  • a centralized location from which to deploy automation projects to Robots
  • an easier and centralized point for the management and monitoring of multiple Robots
  • the scheduled execution of automation processes on Robots
  • the management of queues and transactions
  • centralized Robot logging to SQL and/or ElasticSearch



If a RDP connection is started on the robot machine and this machine loses internet connection, even for few seconds, the Robot throws a “Desktop has been disconnected…” exception.

Updated 2 years ago


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.