- 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
- 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
How is unattended automation performed
The steps below describe the necessary actions for running successful unattended automations. We are aware that such large-scale processes are managed differently by each company, which means that the order in which the steps are performed will vary. Thus, the order described below is merely a recommendation of how a successful setup could occur.
The following steps help you set up your host machine for running unattended automations.
The host machines that will run unattended automations are connected to an Orchestrator machine template, via a machine key or a set of client credentials. This allows automations to be managed from Orchestrator.
Several host machines can be connected to the same machine template. It is, however, a good practice to maintain separate templates for each set of host machines that share the same physical setup, namely:
-
They have the same configuration.
-
They contain the same applications, in the same versions, installed under the same paths on each machine.
-
The users that need to log in to these applications have the same access rights.
To ensure that your host machines run automations as smoothly as possible, there are some important things to keep in mind:
-
All necessary resources, such as applications and services, should be installed on the relevant host machines and grouped in a logical manner, according to the processes that you want to run.
-
All robot accounts assigned to a folder must be able to log in to every host machine associated to the machine template that is assigned to that same folder.
All robot accounts assigned to a folder must be able to log in to every host machine associated to the machine template that is assigned to that same folder.
The host machine must match the Hardware and Software Technical Requirements, and its screen saver functionality must be disabled.
A Service Mode Robot is the recommended option for unattended automation scenarios and large-scale platform deployments. When a process is executed, the Robot is launched by the Windows Service Control Manager under the Local System, which means that it has all the rights of a machine administrator and it can run with the same rights as the user under which it is registered.
There are two ways of installing the Robot:
-
Via the command line, using the
ADDLOCAL
parameter - to install the Robot in service mode, you need to also add theRegisterService
option. This is the recommended choice for unattended Robots, especially where large-scale deployments are concerned. -
Along with UiPath® Studio, via
UiPathStudio.msi
- the Robot is deployed by default in service mode.
We recommend using non-persistent VDIs, which help ensure that all your host machines follow a consistent configuration, with minimum effort.
This step is only necessary for developers that run unattended automations and that might want to troubleshoot any issues.
You can also debug your processes directly from the UiPath Assistant, by enabling a troubleshooting session.
UiPathStudio.msi
on that machine. If you opt for the Quick Setup during installation, the Robot is deployed in User Mode, meaning that it runs under the user that started it, and has the exact rights as that particular user.
UiPathStudio.msi
installer can be downloaded from the Resource Center or directly from the Automation CloudTM home page.
The following steps help you configure the Orchestrator objects that are necessary for running successful unattended automations.
A machine template is the recommended type of Orchestrator machine for unattended automations. Machine templates provide the computational power for executing the job. They help you deploy several machines by defining the configuration once and then using a single set of client credentials to allow multiple robots to connect to Orchestrator.
-
At the tenant level, click Machines > Add machine > Machine template. The Machine template window is displayed.
-
Configure the machine template and assign it minimum one unattended runtime. Runtimes are a type of service license dedicated to unattended automations, and are taken from the tenant pool and assigned at the machine template level. With one runtime, you can run one automation on a host machine. With two runtimes, you can run two automations on the same host machine or one automation on two host machines.
-
Click Provision.
-
Copy the machine key and/or the client ID and client secret for later use.
This is an example of a machine template which serves as the basis for an efficient optimization strategy:
Your infrastructure consists of:
-
one Windows desktop
-
one high-density Windows Server
-
three Linux machines
No. of processes |
Compatibility (set in Studio) |
Machine Template Settings (set in Orchestrator) |
Why |
4 background processes |
Windows - Legacy (.NET Framework 4.6.1) |
We connect one Windows desktop using template A which we define as follows: Process type = Background onlyProcess compatibility = Windows onlyUnattended Runtimes = 4 |
.NET Framework 4.6.1 processes can only run on Windows machines. Background processes can run concurrently under the same account. Template A has 4 runtimes assigned, allowing execution of 4 jobs concurrently. |
6 background processes |
Cross-platform (.NET 5.0 or higher) |
We connect 3 Linux machines using template B which we define as follows: Process type = Background onlyProcess compatibility = Cross-platform onlyUnattended Runtimes = 2 |
.NET Framework 5.0 processes can run on any type of machine. Template B only allows execution of background processes on the connected Linux machines. Background processes can run concurrently under the same account. Template B has 2 runtimes assigned, allowing execution of 2 jobs concurrently on each connected Linux machine: 2 jobs x 3 machines results in an execution capacity of 6 concurrent jobs. |
10 foreground processes |
Windows (.NET 5.0 or higher) |
We connect the Windows server using template C which we define as follows: Process type = Foreground onlyProcess compatibility = Windows onlyUnattended Runtimes = 10 |
.NET Framework 5.0 processes can run on any type of machine, Linux machines included, but because these are foreground processes developed for Windows, you need to run them on Windows machines. One account can run one foreground process at a time. An HD Windows Server allows opening multiple account sessions. Template C has 10 runtimes assigned, meaning 10 sessions are opened simultaneously, allowing execution of 10 foreground jobs concurrently. |
The account is the identity that provides permissions and credentials required for the robot to consume Orchestrator resources and log into host machines respectively. It is recommended to use a robot account, which is ideal when you need to run back-office unattended processes that should not be the responsibility of any particular user.
To create a robot account, follow the steps corresponding to your environment:
It is highly recommended to build a folder structure that’s centered around the processes that you want to run. That is to say each process should have it own specialized folder(s) containing all the assets that are needed for it to run correctly and without interruptions.
The machine template, the robot account, the automation process, and any other elements needed for an iteration of unattended automation should be placed in the same folder. This is very important if you want to ensure uninterrupted processing.
Assigning a robot account to a folder
- At the Orchestrator tenant level, click Folders, select the desired folder for your automation (which must be the same as the one where you added the machine template), then click Assign Account/Group.
- In the Account or Group name field, start typing the name of the account you have just created and select it from the list.
- From the Roles list, select Automation User.
- Click Assign.
Assigning a machine template to a folder
- Select the folder that will contain all elements pertaining to this automation, then click Settings > Machines > Manage Machines in Folder.
- Click Add machine > Machine template. The Manage machines in folder window is displayed.
- Select the checkbox to the left of the desired machine template, then click Update. The machine is added to the folder.
In unattended automation, the host machine is connected and licensed in unattended mode, thus executing processes through Orchestrator. This connection is established through either a machine key or a set of client credentials, via the command line. The machine key or the credentials are generated in Orchestrator when you create the machine template. This is dependent upon the robot security settings.
To find out how to achieve this connection, visit this section.
The following sections walk you through the necessary steps to actually run the automation that you have been preparing so far.
You can either run your automation directly or schedule it to run by setting up a trigger.
Direct run
You can run a job from two places within the target folder of your automation:
1.a. Click Automations > Jobs > Start. In the job settings page that opens, from the Process Name list, select the process you created at step 2.
1.b. Click Automations > Processes, then click the Run a Job symbol next to the desired process. This opens the job settings page with the desired process already displayed in the Process Name field.
2. Configure any other settings in this page, then click Start.
Scheduled run
Triggers allow you to execute jobs in a preplanned manner, either at regular intervals (time triggers) or whenever new items are added to your queues (queue triggers).
Triggers constitute a folder-scoped asset, which means that you can create them by accessing Automations > Triggers from the folder level. Just like all other assets pertaining to an automation, triggers must also be part of the same folder as the corresponding process used for running the unattended automation, as well as the robot account and machine template created for that purpose.
Triggers are created based on an existing process, and they benefit from the same execution priorities as those available at the process and job levels.
If you would like to schedule a recurrent time to start a job, you can create a time trigger.
If you would like to start a process upon trigger creation or whenever you add a new item to a queue, you can create a queue trigger.
How are Robot sessions managed
When the Robot is disconnected, its status in this page changes, and its license is released, thus becoming available for another Robot/process.
Robots are disconnected when the host machine is turned off. They are, however, also deemed unresponsive and disconnected when they do not send a successful heartbeat for two minutes.
How are jobs allocated
Job allocation is performed based on the capabilities of the parts involved in the automation, namely the robot account, the process, the job, and the host machine.
Orchestrator picks up the following information in order to decide how to allocate jobs:
I. It checks the folders for any pending jobs, which it orders based first on priority, then on creation time. Jobs with higher priority and jobs with an older creation time re picked up first.
II. It checks the process type (which is set in Orchestrator):
-
Background process - it can run under any identity
-
Foreground process - the Robot checks for any available credentials, meaning available users within that folder
-
All - both background and foreground processes.
III. It checks the process compatibility (which is set in Orchestrator):
-
Windows only - Windows-compatible processes only
-
Cross-platform only - cross-platform processes only
-
All - both Windows-compatible and cross-platform processes
IV. It checks the job compatibility (which is set in Studio, at creation time):
-
Windows-legacy (.NET Framework 4.6.1) - can only run on Windows machines
-
Cross-platform (.NET 5.0 or higher) - can run on any type of machine
-
Windows (.NET 5.0 or higher) - can run on any type of machine, Linux machines included; however, since these are foreground processes developed for Windows, they need to be run on Windows machines.
V. It checks the infrastructure of the host machine for the compatible Robot version.
- 1. Setting up the infrastructure
- 1.1. Setting up the host machines that will run the unattended robot
- 1.2. Installing a service mode robot on host machines
- 1.3. (Optional) Installing UiPath Studio on the unattended machine
- 2. Setting up Orchestrator
- 2.1. Creating a machine template
- 2.2. Creating a robot account
- 2.3. Creating the folder structure
- 2.4. Assigning objects to folders
- 3. Connecting the unattended robot to Orchestrator
- 4. Executing the unattended automation
- 4.1. Creating an automation project in UiPath Studio and publishing it to Orchestrator
- 4.2. Creating a process in Orchestrator
- 4.3. Running the automation