Robot User Guide

Last updated Dec 4, 2024

Background Process Automation

Note: This is only available for Attended Robots. When using Unattended Robots to run multiple Processes at the same time, each Running Process consumes a separate license.

An Attended Robot operates on the same machine as a human. It is usually triggered by user events and should only be run under human supervision. Read more about the Robot's automation capabilities according to license.

Background Process Execution is performed by a Robot on a machine for a particular user. Processes run in the same Windows session at the same time.

Each running process uses its own version of dependencies, even if multiple running processes require a different version of the same dependency. For example, if process A requires dependency v18.4.6 and process B requires dependency v19.4.4, then each process downloads and uses its required version of the dependency.

According to this type of license, an Attended Robot can concurrently execute one foreground process (with UI interaction) and multiple background processes (without UI interaction).

A foreground process is used when your automation project needs to interact with UI elements. These processes heavily rely on UIAutomation activities. Please note that you can only execute one foreground process at a time.

Important: Automation processes that use UIAutomation activities cannot run under a locked screen.

A background process doesn't need to interact with UI elements on the screen but rather relies on background processes to pass along information. UIAutomation activities should not be used in these project types. Multiple such processes can simultaneously run on a machine, even if a foreground process is already running.

The type of process is generally dictated by the type of activities it uses (whether or not they interact with UI elements). However, you can specify the type when you create a new process from Studio. By default, all processes are marked as foreground, unless specified otherwise.

Attended and Unattended Robots Behavior

During start-up, a Windows Session is created for the System Processes to run which are not related to a specific user, this is called Session 0. This session allows Windows to run system processes needed for the machine itself. When a user logs on to that machine, a new session is created called User Session in which user-specific services run.

For a more detailed description, the Session 0 Isolation document from Microsoft provides additional information on how sessions are created and information is handled between them.

Using background processes offers a different behavior when they are run in Attended vs Unattended automations. Background Processes started from an Attended Robot run in the user's session (Session 1) while the ones started from Unattended Robots run in the Windows Session.

Attended Robots

Background Process Automation with Attended Robots rely on the user's session on the machine to run automations, these are started from Studio or UiPath^® Assistant and run in the same Windows Session as the user. As the automation happens in the same session, the robot is able to retrieve information and access files that are specific to the user.

Unattended Robots

Background Process Automation with Unattended Robots are started from via the Robot Service and run in the Windows Session (Session 0). It's important to know that Session 0 has no User Interface and cannot interact with a user session. When using this type of processes on Unattended Robots keep in mind that they run in the name of the user and they inherit its permissions. Make sure that the user under which the process runs has access to the needed resources and that the process does not require any type of User Interface. See the Windows Session document for more details on how windows sessions are being handled by the UiPath^® Robots.

Note: When running Background Automations via Unattended Robots, using Microsoft Office applications such as Word, Excel or PowerPoint might not work properly as they have been built to run in User-Session, meaning that they need an interactive desktop session and user profile. For additional information on how Office 365 Products work with Server Sessions(session 0), see the Server-side Automation of Office document from Microsoft.

Running Background Processes

A Background Process can be transitioned to Foreground with the help of Use Foreground Activity. More details on how this activity works and how to use it in building your automation can be found here.

As long as at least one process is running, the Robot is marked as Busy in Orchestrator.

Important: Starting with the 2021.10 release, running unattended background automations on service-mode robots run by default under the built-in "Local Service” Windows user. Prior to this, the username and password configured for the robot in Orchestrator were used.

To use credentials specified in Orchestrator, you need to configure the UIPATH_HEADLESS_WITH_USER system environment variable on the robot machine and set the value to True.

Running automations under the Local Service account is lightweight as it does not need login credentials set in Orchestrator. This has the following limitations:

In automation workflows, access is limited to Local Service account privileges.
Proxy configurations for the executor are not supported.

Starting another foreground process while one is already running is not possible. Background processes, on the other hand, can be started regardless of the state and type of the other processes.

You can use the Run Parallel Process activity in your background processes to start other processes, based on triggers you need. Processes started by this activity run independently. For example, a background process which monitors particular actions can start a new process (foreground or background) and continue to monitor the specific action without being interrupted. A background process loaded by this activity starts right away, even if a foreground and one or more background processes are already running. If the activity starts a foreground process, one of the following situations occurs: