Robots

The UiPath Robot is the execution host that runs processes designed in UiPath Studio. In Orchestrator, the robot object represents the image of the UiPath Robot and helps define its capabilities and access to Orchestrator resources.

This guide's purpose is to provide context and instructions related to the Orchestrator objects. For more details about how to install and configure the UiPath Robot, visit the Robot guide.

Common Terminology	Meaning
UiPath Robot	The execution host that runs processes designed in UiPath Studio.
Robot (Orchestrator object)	Orchestrator object used to define the capabilities and privileges of a UiPath Robot such as access to folder resources, machine login credentials, etc. In this guide, it is often referred to as robot, robot object, robot entity.
Machine (host machine)	The physical or virtual machine used to host and deploy a UiPath Robot. In this guide, it is referred to as a host machine, workstation or server, to differentiate it from the machine object in Orchestrator.
Machine (Orchestrator object)	Orchestrator object that works as an API key generator, authorizing the usage of a UiPath Robot on a host machine. For unattended use cases, it also allows administrators to configure the execution capacity for the associated host machine(s).

Attended Robots

Attended robots act as the personal assistant of end-users such as HR personnel, Call Center operators, etc. Because attended automation must run under human supervision, it is best suited for smaller, more fragmented tasks. For example, the submission of an expense report is a task that lends itself to attended automation, where the user provides the credentials to log in to the system and the automation then fills in the requisite information, attaches any needed items, and submits the report on the user's behalf.

As there is always a human user present, attended automations must not be created with or granted permissions to perform tasks the user themselves could not. Any credentials required during the execution of an attended process should always be credentials that the user triggering the automation knows and provides themselves.

This is because there is no way to ensure security isolation between running automation and the machine user. If the automation itself performs actions the user does not have access to, it would thereby allow that user access that they are not otherwise granted. Taking the expense report example from above, if bundled in that automation is also the process of approving expense reports, the user could simply pause or stop the automation after it has logged in to the approval system and then approve any report in any amount, an action they could not perform with their own credentials.

Because attended robots impersonate real individuals, they should run under user accounts.

Note:

You cannot typically start or trigger processes in Orchestrator on attended robots, and they cannot run under a locked screen. They can only be started from UiPath Assistant or the Command Prompt.

An exception to this rule is process debugging, where users, generally RPA developers, can launch processes from Orchestrator on attended robots. This can be done via personal workspaces which allow launching processes in Orchestrator on attended robots by using the machine template automatically generated by virtue of being a personal workspace owner. Read more about personal workspaces.

Where Does Orchestrator Come Into Play

Orchestrator ensures the centralized management and delivery of automation resources (assets, queues, package versions, storage buckets, etc) to robots for execution.

Where Does the Assistant Come Into Play

The Assistant works as a user's sidekick in executing processes, allowing the attending user to manage and run automations with a few clicks. From a technical standpoint, the Assistant is the client of the user-mode Robot service, which is the brain behind all operations performed during automation execution.

The User Mode Robot Service

The User Mode Robot is best suited in attended automation scenarios as it runs under the user that starts it and has the exact rights as that particular user.

By default, the start of the Robot Service is triggered by user sign-in when the service is set to run at login time. If it's not set to run at login time, opening the UiPath Assistant starts it automatically.

Attended Licensing

To perform attended operations, the user under which the robot runs must be assigned a license that provides that user rights to use the Attended Robot or you can license the Robot locally from the Command Line. Check out the UiPath Licensing Portal for more information about available SKUs.

Attended Robot Access to Folder Resources

Robots in modern folders run under certain accounts - user or robot accounts - meaning robots run in the context of the corresponding identities. Those identities and their association with roles allow for a certain level of access to resources in Orchestrator.

To provide an attended robot with access to the resources in a folder, an administrator must add the underlying account to that folder. The account must also be granted the permissions to perform the operations required by the processes contained in that folder, or at least, by the processes they will execute - if, for instance, some processes only run under a specific account.

Unattended Robots

Unattended robots are autonomous robots that don't require human supervision to execute jobs. Unattended automation is intended for complex and highly repetitive tasks, usually needing to be performed in batches, that can be decided based upon a predefined rule. Additionally, unattended automation is suited to processes that perform privileged operations, requiring elevated permissions and credentials.

The approval of an expense report would be such a task. The automation, with no human user present, would log in to the necessary system and then process any submitted expense reports and, if they match a defined rule (e.g. under a specified amount), automatically approve them.

In this example, the unattended process is provided the access to approve the expense reports through credential assets that are configured by the administrator. This provides security isolation as the automation developers only reference credentials to be provided, as a clear audit chain has records of who obtains and manages the credentials used by the automation.

Unattended robots can run without humans interfering, as they operate on a trigger-based logic meaning end-to-end unattended process execution is fully automated and unfolds as triggered by certain events defined in the process flow, as opposed to attended robots where a process cannot be automated throughout so it needs human directions to perform certain activities.

Unattended robots should run under robot accounts, special accounts dedicated to applications or virtual machines, not persons.

Where Does Orchestrator Come Into Play

Orchestrator is the central hub for unattended automation as it allows launching unattended execution on the spot or by setting it up in a preplanned manner with triggers. It also manages the resources to be used in automation projects and consumed by robots, and access to them through support for hierarchical structuring combined with fine-grained role assignment.

Orchestrator can also distribute the workload to unattended robots, and when allowed to distribute the workload dynamically (with no constraints), can maximize efficiency and optimize robot usage.

Where Does the Assistant Come Into Play

UiPath Assistant is used to assist users with attended automations. In unattended scenarios, the Assistant is used solely for debugging purposes, when a user logs in to the unattended machine to look for and fix potential issues. In other words, unattended robots can be used in attended mode in a production environment for logging/testing/debugging purposes.

The Service Mode Robot Service

The service-mode Robot is best suited in unattended automation scenarios and large-scale platform deployments. When a process is executed, the Robot Executor runs with the same rights as the user under which it is registered.

The Robot Service is the brain behind all operations performed during execution, and for unattended execution is launched under the Local System. It can open interactive Windows sessions and has all the rights of a machine administrator. As such, it enables automatic session management (such as log on and log off) for unattended jobs.

Installing the Robot using UiPathStudio.msi deploys the Service Mode Robot by default. It can also be installed from the Command Prompt.

Note: Unattended automation works best with Service Mode Robots, installed under Local System. Unattended robots can also run under the Local User (User Mode Robots), but this is not the recommended approach since the robot cannot run unless that particular user is logged in to that machine.

The Service Mode Robot gets installed for all users on a machine. When the Service Mode Robot is installed on Windows Server machines, you can run concurrent unattended jobs with automatic session management. This represents the seamless unattended automation scenario. You can have concurrent jobs with the User Mode Robot on a Windows Server, but no automatic session management.

Learn more about high-density robots in the Robot guide.

Learn how to set up Windows Server for HD Robots.

Unattended Licensing

Unattended robots are licensed by allocating a runtime (execution slot) on a machine object - either a standard machine, or a machine template. Therefore Unattended, NonProduction, or Testing runtimes must be assigned at the machine object level.

Say you have a machine template defined with 10 unattended runtimes. For each workstation connected using the key generated by that template, a pool of 10 licenses is reserved from the total number of licenses at the tenant level. A runtime is only consumed from the pool of licenses of the tenant while a machine is connected to Orchestrator. If you connect 4 machines to Orchestrator using that template, you need 40 unattended runtime licenses at the tenant level. With 25 jobs running, there are still 15 slots available for execution.

Unattended Robot Access to Folder Resources

Robots in modern folders run under certain accounts - user or robot accounts - meaning robots run in the context of the corresponding identities. Those identities and their association with roles allow for a certain level of access to resources in Orchestrator.

To provide an unattended robot with access to the resources in a folder, an administrator must add the underlying account to that folder. The account must also be granted the permissions to perform the operations required by the processes contained in that folder, or at least, by the processes they will execute - if, for instance, some processes only run under a specific account. Additionally, a machine template with enough runtimes must be assigned to the folder. This operation allows you to specify the infrastructure (host machines) that can be used for executing automations in those folders and ensures they have slots available for execution.

Unattended Robots With or Without Credentials

With credentials

Since unattended automation implies the lack of a human agent, unattended robots often need to be provided with the credentials to log in to the host machine, such as for automation projects that interact with the user interface. UiPath supports several credential types:

• Username/Password Credentials - This is the default method.
• SmartCard Authentication

• HSM: Luna Credential System, nShield Key Storage Provider

  Note:

  The username and password used for authentication purposes are transmitted only on heartbeats, enabling it to log in and execute processes.

  You cannot execute unattended processes that interact with the UI unless you provided the correct machine login credentials.

Without credentials

Unattended robots handle background processes in Session 0, under NT AUTHORITY\LOCAL SERVICE, which has no UI and cannot interact with a user session. For this reason, you don't need credentials for executing background processes. You do, however, need credentials for executing foreground processes,

Process type	Credential considerations	Robot version
Background	Robot with credentials	Any
Foreground	Robot with credentials	Any
Background	Robot without credentials	2021.10+
Foreground	Robot without credentials	Invalid configuration! Jobs cannot be executed.

Floating Robots

Floating robots are robots that enable users to use UiPath Robot on multiple workstations, as the robot is not tied to a specific machine. All robots in modern folders are floating robots. With one Named User license, one user can use UiPath Robot on a maximum of three machines at a time.

A user that wants to change one of the three workstations they're working on requires them to log out of a previously used machine and log into the new one.

Example

My name is John Smith, I am a call center operator in a team of 20 working on whatever laptop I find available when I get to work. In Orchestrator, my system administrator needs to define one machine template for the 20 laptops we have, and a floating robot using my username. This enables me to use each of the 20 laptops using my username and the key generated by the machine template.

Standard Robots

Standard robots are the predecessors of floating robots, and you can only find them when working with classic folders. A standard robot restricts the user to use UiPath Robot on a single workstation, as the robot is tied to a specific machine, namely the one set when creating the standard robot in Orchestrator. Standard robots work only for users who always work on the same machine or whose name stays the same each time the user connects to it.

Changing the workstation requires deleting the initial standard robot and recreating it using the name of the new standard machine.

Example

My name is John Smith, I am a call center operator working daily on the same laptop whose name is LA4324. In Orchestrator, my system administrator needs to define for me a standard machine with the same exact name as my laptop, and a standard robot using my username, robot configured to connect to the standard machine named LA4324. If I ever change my laptop, the system administrator needs to delete this robot, and create a new one, for the new machine.