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 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.
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.
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.
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.
Background Process Automation with Unattended Robots are started from the 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.
You can not start processes from Orchestrator on this type of Robot. They can only be started from the Robot Agent (tray), or from the Command Prompt.
With the v2020.4 Release, you can now transition a Background Process 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.
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:
- The process starts right away if there is no other foreground process running.
- An exception is thrown if a foreground process is already running.
Updated 8 months ago