- Getting started
- Best practices
- Organization Modeling in Orchestrator
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Accessing the unattended robot setup
- Useful concepts in unattended automation
- How is unattended automation performed
- Organizing Resources With Tags
- Orchestrator Read-only Replica
- Exporting grids in the background
- 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
- Audit
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Useful concepts in unattended automation
Unattended automations rely on various components that are useful to grasp. The topics below briefly define these components, but further details are available at each step where the concepts are used.
Robot accounts are helpful when you need to run back-office unattended processes that should not be the responsibility of any particular user. These are our RPA-specific equivalent of service accounts. Similar to the accounts that Windows services run as application identities in the OAuth model, they are a non-user identity to be used to run unattended processes. This makes them ideal for highly privileged operations that need credentials.
Find out how to add a robot account.
When you assign a robot account to a parent folder in a folder hierarchy, the robot account automatically gets access (with the roles assigned at the parent folder level) to all subfolders created under the specific folder. New permissions can be added in the subfolder on top of the ones assigned at the parent folder level, but the inherited roles cannot be removed. It is possible for a robot account to have a greater access level at subfolder than at parent folder level, but the reciprocal is not true.
Granting a robot account access only to a subfolder is possible by assigning it directly at the subfolder level. This way, the robot account will have no visibility to the parent level, but will be able to access all resources in the subfolder and underneath it, according to the assigned role definition. Assigning a robot account at subfolder level does not grant it access to the folder’s siblings, namely to other folders of the same level, unless it is explicitly assigned to the other same level folders as well, or if it is assigned at parent level (which would grant it access to all folders underneath, as mentioned previously).
If resources from other folders are needed for running the processes in the current folder, you need to make sure all the robot accounts under which the specific processes will run are also assigned as robot accounts of the folders where the rest of the resources are located, with enough permissions to be able to access/create/modify/delete the resources from those folders, as required by the processes.
You can manage several robot accounts by adding them to a group. Groups are a collection of accounts which should have similar access, robot configuration, and licensing needs, and which you want to manage together. It is therefore only recommended to group robot accounts that share the same settings and use cases. For instance, if you have five robot accounts that handle foreground automations on Windows machines, and 10 robot accounts handling background automations on Linux machines, you would add each category to its own group, but you never combine them.
Groups can be very helpful for leveraging scalability in the context of robot deployment and permissions control, thus eliminating the need for individual configuration of robot accounts.
Find out how to add groups to on-premises Orchestrator.
Find out how to add groups to cloud Orchestrator.
The Robot is UiPath®’s execution entity. It can run either in service mode or in user mode, depending on the type of automation.
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.
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 manually 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 a seamless unattended automation scenario. You can have concurrent jobs with the User Mode Robot on a Windows Server, but no automatic session management.
The User mode Robot is best suited in attended automation scenarios. It runs under the user that starts it, and has the exact rights as that particular user.
Choosing the quick install option in the .msi installer deploys the robot in user mode by default.
UiPath Assistant is the interface of your Robot, allowing you to interact with projects created in Studio.
In unattended scenarios, however, Assistant is used solely for debugging purposes, when a user logs in to the unattended machine to look for and fix potential issues.
Machine templates are the recommended type of machine for unattended automations. Machine templates make it easier to deploy several host machines by defining the configuration once and then allowing multiple robots to connect to Orchestrator. They enable you to connect UiPath Robots deployed on multiple host machines to Orchestrator, regardless of the names of the host machines or the users logging onto them.
Machine templates, as their name suggests, work as templates whose settings apply to groups of host machines with the same physical setup. Several host machines can easily be connected to the same template through a key or a set of client credentials. The key or the robot credentials are used by robots to log in on host machines and access Orchestrator resources.
When grouping host machines under the same machine template, we recommend you follow these practices:
-
The host machines have been deployed based on a shared template, or at least configured as if they were.
-
The same applications should be installed on the machines, and quite importantly, the applications should be installed at the same paths on each of the machines, and they should all share the same version of the applications.
-
The users logging into the applications on these machines should all have the same access rights to the applications on them.
One important aspect to keep in mind is that the algorithm for starting unattended automations can launch a job under any of the users assigned to a folder (unless a specific user is manually selected), and of course, on any host machine assigned to the machine template. It is therefore important that all the accounts that can be picked up for execution have a corresponding account on all the machines assigned to that folder. Otherwise, errors will most likely occur. In order to avoid that, it is important to either make sure the users you want to pair with a specific machine template have been created on all machines in the template, or to have separate templates, each with less machines and the associated users, such that only valid combinations are defined for each folder.
You have the following entities:
-
Folder F1 containing
-
robot accounts R1, R2, R3
-
machine template T1
-
-
Machine template T1 connected to the host machines M1 and M2
In this scenario, you need to make sure that both M1 and M2 have accounts defined with the same credentials as robot accounts R1, R2, and R3. That way, the automation can run under any robot-machine combination.
AllUsers, ContactCenter, and ContactCenter_ITIssues, then this user will share the same setup as the rest of the users in ContactCenter_ITIssues, and should also share the same Orchestrator machine template as the rest of the aforementioned users. It is also advisable
that machine templates be created, if possible, in accordance with the existing Active Directory structure.
In order to perform unattended automations using unattended robots, you need a dedicated service license. This is called a runtime and is assigned to a machine object used to execute unattended processes. To do that:
-
At the tenant level, access Machines.
-
Select the desired machine and click More Actions.
-
In the Runtime details section, insert a number or use the up arrow to input a number of runtimes in the Production (Unattended) field.
The number of runtimes assigned to a machine object represents the execution capacity for running automations on each host machine that is attached to that machine object. Where unattended automation is concerned, the preferred machine object is the machine template.
Runtimes are allocated at the tenant level, and, as such, constitute the tenant's pool of runtimes. When a host machine connects to UiPath Orchestrator, the number of runtimes assigned to its associated machine object is retrieved from the tenant pool. The runtime is consumed during the execution of a process on the machine. When the host machine disconnects, the runtimes return to the tenant pool.
Example 1
You have a machine template to which you assign three unattended runtimes:
-
If you connect one host machine to that machine template, you can run three automations on the host machine.
-
If you connect three host machines to that machine template, you can run three automations on each of the three host machines, so a total of nine automations.
When assigning runtimes to a machine template, make sure you assign enough of them to cover all the unattended/testing/nonproduction executions that can happen simultaneously across all folders where the machine template is defined. This also requires having enough machines connected to cover all the simultaneous executions.
Example 2
You have:
-
10 unattended jobs scheduled to start simultaneously in Folder A
-
5 unattended jobs scheduled to run simultaneously in Folder B (overlapping with the 10 defined in Folder A)
-
one machine template, TemplateAB, assigned to both Folder A and Folder B
You will then have to assign 15 unattended runtimes to TemplateAB and actually have 15 identical machines available and connected to the machine key of TemplateAB in order to make sure the execution is possible for all the defined schedules.
The only exception from the above rule are background processes, where you need enough runtimes assigned to your template for all your simultaneous process executions, but not as many host machines connected to the template, since you can run virtually as many background processes as you need on the same machine, but only one foreground process (process which requires UI) at a time.
Example 3
For 10 simultaneous background processes and 1 foreground process, only one host machine connected to a template is enough, but that specific template needs to have 11 runtimes assigned to it. If, however, a second foreground process is added, and it has to run at the same time as the first foreground process that was defined, or if the first foreground process needs to be executed twice simultaneously, a second machine connected to the machine template will be needed for the execution of both instances of the foreground process to be possible.
The Robot Tiers section of the UiPath Licensing Portal shows the full list of available runtimes.
Processes are based on Studio automation packages. They are a per folder resource and can only run in the folders where they are deployed. They can, however, be started by processes in other folders, provided that the users in those specific folders have the necessary permissions in the folder where the desired process is deployed.
There are two types of processes you can work with:
-
Background processes do not require user interface interactions or human intervention.
-
Foreground processes need to be started and/or managed from the user interface, and can only be run one at a time.
Notes:
-
Each execution of such a process consumes an Unattended/NonProduction runtime.
-
You can execute multiple background processes and one foreground process simultaneously.
When creating a project in Studio, developers must configure a compatibility attribute that impacts the underlying target framework of the automation project and the compatible operating system. This is set in Studio, in the Compatibility field.
The following table shows the UiPath Robot version required to execute processes according to their target frameworks and OS compatibility considerations:
|
Target framework |
Operating system |
Robot version |
|
.NET Framework 4.6.1 |
Windows - Legacy |
Any |
|
.NET 5.0+ |
Windows |
2021.10+ |
|
.NET 5.0+ |
Cross-platform |
2021.10+ |
Machine template settings
UiPath can manage the robot pool on your behalf, in Automation Cloud, allowing you to choose both your own level of involvement, as well as that you assign to us.
You can benefit from this feature by creating one of the following types of machines (tenant level > Machines > Add machine):
-
Elastic Robot Pool - robots are managed by UiPath, and you decide how much of the orchestration process you want to outsource.
-
Cloud Robot - VM - UiPath handles the orchestration process and provides you with a virtual machine on which to run automations.
