Attended vs. unattended

The first decision to be made when planning your automations is whether the solution is to be executed in an attended or unattended context. While both types are intended to automate tasks a user would otherwise perform manually on their computer, the specific use cases are different between them.

Attended automations

What are attended automations

Attended automations are designed to run under human supervision, making them ideally suited for smaller, more fragmented tasks, such as submitting expense reports. For example, once the user logs into the system, the automation takes over to fill in necessary information, attach requested items, and submit the report.

To ensure security, attended automations should only be permitted to undertake tasks or actions that fall within a specific user access rights. This preventive measure is important because there is no security isolation between an active automation and the user controlling it. Users must provide all required credentials during the execution of an attended process. If the automation executes actions outside of the user access, it unknowingly provides the user with unauthorized access. For example, if an expense report automation also includes approval access, the user could potentially manipulate the automation to approve any report, an action not ordinarily permitted with their own credentials.

Where does Orchestrator come into play

In attended automation, Orchestrator ensures the centralized management and correct delivery of package versions to robots for execution.

To allow an attended automation access to resources in an Orchestrator folder, the administrator has to add the corresponding account (either a user or a robot account) to that specific folder. The account also needs permissions for operations required by the automation within the designated folder. For example, some automations might run exclusively under a specific account.

Where does Assistant come into play

The Assistant works as a user sidekick in automating 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

The User Mode Robot is best suited in attended scenarios, as it runs under the local user that starts it and has the exact rights as that particular user. By default, the Robot Service starts when a user signs in, assuming it is configured to start upon login. Otherwise, opening the Assistant starts the Robot Service automatically.

Licensing

To perform attended operations, the user under which the robot runs must be assigned a license that provides that user rights to use attended licenses. This involves Attended, Citizen Developer, and Automation Developer user licenses.

Authenticating

To authenticate robots in order to execute attended automations, Orchestrator verifies the identity of the UiPath Robot that needs to access Orchestrator resources. Validating that identity determines a trust relationship for further interactions.

For attended automations, there are two methods to authenticate robots: interactive user sign-in (Service URL in Assistant) and a hybrid option allowing for both user sign-in and machine key connections. These authentication options are found in Orchestrator > Tenant > Settings > Robot Security.

Interactive Sign-in SSO (Recommended) - This option only allows for robot connections with tokens that expire. Users can authenticate their robots only by signing-in with their credentials in Assistant. User sign in is required to run attended automations, make Orchestrator HTTP requests, or view automations in Assistant. When using interactive sing-in, there is no need to create machine objects in Orchestrator.

Hybrid - This option allows for both connections with tokens that do not expire (machine key) and connections with tokens that expire (interactive sign-in or client credentials). Users have the option to sign-in with their credentials to authenticate their robots, which in turn allows them to connect Studio and Assistant to Orchestrator, however it is not mandatory.

Unattended automations

What are unattended automations

Unattended automations are designed for complex, repetitive tasks, typically done in bulk, based on certain rules. Unlike attended automations, which require human guidance, unattended automations operate independently, based on triggers or specific task events. By avoiding human intervention, they are ideal for tasks requiring elevated permissions.

For example, an unattended automation can approve expense reports. It logs into the system, checks the reports, and if they match a rule (such as being under a certain amount), it approves them.

It is the administrator persona that gives the unattended automation access to the system. This ensures security as it provides a clear record of who manages these details.

Where does Orchestrator come into play

Orchestrator serves as the core hub for unattended automation. It enables instant or scheduled execution of unattended tasks through triggers, and it can dynamically assign unattended tasks to available robots. In addition to managing resources needed for automation projects, it controls access to them through folder hierarchies and specific role assignments.

An admin sets up unattended automation in a folder by granting a user or robot account access and necessary permissions. They also assign a machine template ensuring it has enough runtimes for executing the automation.

Where does Assistant come into play

Assistant is the UiPath tool designated for assisting users with attended automations. In unattended scenarios, Assistant is used solely for debugging purposes, when a user logs in to the unattended machine to look for and fix potential issues.

The Service Mode Robot

The Service Mode Robot is best suited in unattended scenarios and large-scale platform deployments. The Robot Executor runs unattended automations with the same privileges as the registered user. The Robot Service runs under the Local System, opens interactive Windows sessions, and has the rights of a machine administrator. This allows it to manage sessions automatically (such as logging on and off) for unattended automations.

Licensing

To perform unattended automations, you need to assign runtimes to the machines - physical or virtual devices where unattended tasks are executed. These machine runtimes can be of the following types: Unattended, NonProduction, and Testing.

For example: say you have a machine template with ten unattended runtimes. Each machine connected with this template reserves ten licenses from the total available. These licenses are only used when an unattended automation is executed. So, if you connect four machines using this template, it reserves 40 licenses. With 25 jobs running, 15 slots remain available.

Authenticating

For unattended automations, there are two methods to authenticate robots: client credentials and a hybrid option allowing for both client credentials and machine key connections. These authentication options are found in Orchestrator > Tenant > Settings > Robot Security.

Client Credentials (Recommended) - Client credentials allow the Robot to access Orchestrator resources by using its own credentials, instead of impersonating a user. When the robot requests resources from Orchestrator, Orchestrator enforces that the robot itself has authorization to perform an action since there is no user involved in the authentication. It uses the OAuth 2.0 framework as the basis for the authentication protocol, meaning robots can connect to Orchestrator with a client ID - client secret pair generated via machine template objects. The client ID - client secret pair generates a token that authorizes the connection between the robot and Orchestrator and provides the robot with access to Orchestrator resources. The admin has the option to revoke access at any time by deleting the secret employed on that machine.

Hybrid - This option allows for both connections with tokens that don't expire (machine key) and connections with tokens that expire (client credentials).