- Getting started
- Best practices
- Tenant
- About the Tenant Context
- Searching for Resources in a Tenant
- Managing Robots
- Connecting Robots to Orchestrator
- Storing Robot Credentials in CyberArk
- Storing Unattended Robot Passwords in Azure Key Vault (read only)
- Storing Unattended Robot Credentials in HashiCorp Vault (read only)
- Storing Unattended Robot Credentials in AWS Secrets Manager (read only)
- Deleting Disconnected and Unresponsive Unattended Sessions
- Robot Authentication
- Robot Authentication With Client Credentials
- Configuring automation capabilities
- Solutions
- Audit
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Integrations
- Troubleshooting
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 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.
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.
Orchestrator ensures the centralized management and delivery of automation resources (assets, queues, package versions, storage buckets, etc) to robots for execution.
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 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.
UiPathStudioSetup.exe deploys the User Mode Robot by default. It can also be installed from UiPathStudio.msi, or the Command Prompt.
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.
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.
Robots 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 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.
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.
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 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.
UiPathStudio.msi deploys the Service Mode Robot by default. It can also be installed from the Command Prompt.
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.
For unattended robots, licensing is performed per allocated runtime (slot) entity instead of per user. That's why Unattended, NonProduction, Testing runtimes are 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 reserved licenses during job execution. 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.
Robots 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.
A. 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.
-
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.
B. Without credentials Unattended robots handle background processes in Session 0, underNT 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 are robots that enable users to use UiPath Robot on multiple workstations, as the robot is not tied to a specific machine. 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.
- Attended Robots
- Where Does Orchestrator Come Into Play
- Where Does the Assistant Come Into Play
- The User Mode Robot Service
- Attended Licensing
- Attended Robot Access to Folder Resources
- Unattended Robots
- Where Does Orchestrator Come Into Play
- Where Does the Assistant Come Into Play
- The Service Mode Robot Service
- Unattended Licensing
- Unattended Robot Access to Folder Resources
- Unattended Robots With Credentials Vs Without Credentials
- Floating Robots
