Robot Executor

Configure and manage the UiPath Executor, the Robot component that runs automation workflows in isolated sessions.

UiPath Executor is a component of the UiPath software structure that is used to run automations or jobs. It is the component that actually executes the automation workflows, and you can identify it in the list of running processes as UiPath.Executor.exe.

How it works

During an automation lifecycle, the Executor represents the execution stage:

1. Design stage—Once an automation workflow is designed and created in Studio, it is then published to Orchestrator.
2. Orchestrator stage—The Orchestrator is the component that manages, controls, and logs the operations executed by the robots. Here, you can schedule a job or run it on-demand.
3. Execution stage—When a task is scheduled or triggered, Orchestrator sends a command to the Robot Service. The Robot Service then starts instances of UiPath Executor to run the automation task. Each instance operates in an isolated session, ensuring that if one task fails, the others remain unaffected.
4. Post-execution stage—When the task is completed, Executor instances are terminated, and the results are sent back to the Orchestrator. Details such as execution time, status (success or failure), and any exceptions are logged and can be analyzed for troubleshooting or process improvement.

Capabilities

Some of the Executor capabilities include:

• Executing local or remote tasks—UiPath Executor can execute tasks both in the local device where the Robot Service is installed, or it can connect to other devices remotely and execute tasks there.
• Running jobs concurrently—The Executor is capable of performing multiple automations at the same time, each one operating as an independent session.
• Load balancing and task prioritization—Together with UiPath Orchestrator, the Executor can help balance automation loads across multiple robots and prioritize tasks based on predefined rules.
• Maintaining workflow isolation—Each execution in the Executor is isolated, implying that error or failure in one job does not impact the performance of the rest.
  Note:

  The Executor adjusts to different DPI settings, enabling workflows to run on any resolution. If some applications cannot handle DPI, you can disable this particular feature.

Executor types based on automation projects

Based on the automation project, the robot service launches the relevant executor type intended to execute the automation. The following tables summarizes the project types an executor can run, based on the used target framework.

Project/Executor type	Architecture	Supported OS	Framework used
Windows - Legacy	32-bit	Windows (x64 and x86)	.NET Framework 4.7.2
Windows	64-bit	Windows x64	.NET 10 with Windows support (.NET Core - Windows)
Cross-platform	64-bit	Windows, Linux (64-bit)	.NET 10 with cross-platform support (.NET Core)

Each row in the table represents a different executor type, showing how it is configured to run projects based on the specific requirements of the project type, the target operating system, and the.NET framework version used. This information helps understand which executor is appropriate for each project, ensuring compatibility with the target environment and leveraging the relevant framework capabilities.

The Executor and executor packages

The Executor is the .NET executor of Unified Runtime, and runs RPA processes and test cases. By default, agents, functions, and API workflows don't run in UiPath.Executor.exe. They run in executor packages, in a separate host process that the Robot Service starts. The settings on this page, such as preloaded executors, Medium+ integrity, and UIPATH_HEADLESS_WITH_USER, apply to the Executor only.

User configurations for the Executor

The Executor has a dedicated system variable UIPATH_HEADLESS_WITH_USER, which you can configure depending on the type of user that runs the automation.

When the user is Local Service, you can run background automations. Here, the setting for UIPATH_HEADLESS_WITH_USER should either be Falseor not set at all.

When the user running the automation has credentials specified in Orchestrator, there are two scenarios you should consider:

• For background automations, the UIPATH_HEADLESS_WITH_USER setting should be True.
• For foreground automations, there should be no UIPATH_HEADLESS_WITH_USER variable set.

The following table summarizes the user conditions for the Executor.

User type	Automation type	UIPATH_HEADLESS_WITH_USER setting
Local Service	Background	False or null
User configured in Orchestrator	Background	True
	Foreground	No need for a variable

Preloaded executor

Usually, each process requires time to load the required workflow, packages, and libraries into memory before it can start processing. In a preloaded setup, those dependencies are already loaded into memory, in dedicated execution slots. A preloaded executor is enabled by default in User Mode. Preloaded executors exist only in User Mode: in Service Mode, the Robot doesn't start them, and the variables below have no effect.

Here are some key details about the preloaded executor:

• Faster execution: By preloading the process, your robots can start working on their tasks much quicker.
• Resource utilization: With a preloaded executor, robots consume fewer resources by already having the required workflows loaded in memory.
• Availability: Preloaded executors are primarily designed for attended automations started from Assistant, RobotJS, Studio, or the command line interface. Unattended jobs from Orchestrator initiate a single, non-preloaded executor.

System variables for preloaded setup

You can manage the behavior of preloaded executors by setting specific environment variables on the robot machine, as follows. They apply to User Mode robots only:

Environment variable	Value	Description
UIPATH_PRE_LOADED_EXECUTOR	None	Overwrites the default behavior and starts the preloaded executor only when the first job starts.
UIPATH_DISABLE_PRE_LOADED_EXECUTOR	True	Disables the preloaded executor.

How it works

When you add the UIPATH_PRE_LOADED_EXECUTOR variable to your system, you configure a preloaded setup. This starts two executors: one whenever a job starts, and another one to wait for future jobs - the preloaded executor. When another job starts, it uses the preloaded executor, and it spawns another preloaded executor to wait for the next job. In short, a preloaded setup always make sure there is an available executor waiting for jobs.

Preloaded executors and operating systems

For Windows devices, when UiPath.Service.UserHost.exe starts in User Mode, it launches two preloaded executors: one for Windows projects, and another for Windows-Legacy projects.

Medium+ integrity elevation

Some Windows applications run at a higher integrity level than the standard user session. One common example is the Windows CredentialBroker dialog, which appears when you enter a username and password to connect to a Remote Desktop (RDP) session. Because the CredentialBroker runs at Medium+ integrity, the Executor cannot interact with it by default, and your automation fails to type credentials into the dialog.

To enable the Executor to automate such windows, set the UIPATH_MEDIUMPLUS_EXECUTOR machine (system) environment variable to 1. When this variable is set, the Robot Service launches the Executor at the Medium+ integrity level, allowing it to interact with windows that would otherwise be inaccessible.

Alternatively, to elevate only specific invocations instead of the entire Executor, set the UIPATH_MEDIUMPLUS_INVOKE machine (system) environment variable to 1. When this variable is enabled, the Invoke Workflow File and Invoke Process activities can run at the Medium+ integrity level on a per-invocation basis, leaving the rest of the automation at the standard integrity level.

Elevation applies only to invocations that request it — the activity's elevation option must also be enabled; the variable alone does not elevate anything.

The elevation option requires UiPath.System.Activities 26.6.0 or later, and for Invoke Workflow File it applies only when the workflow is invoked isolated. As with UIPATH_MEDIUMPLUS_EXECUTOR, this feature is Windows-only and requires UAC to be enabled.

Requirements

• Windows only — this feature is not available on Linux.
• UAC must be enabled — the elevation relies on User Account Control being active on the machine. If UAC is disabled, the variable is ignored and the Executor starts at the default integrity level.
• Installation mode — the Robot must be installed either in service mode or in user mode with a per-machine installation (installed in Program Files). Per-user installations do not support Medium+ elevation.
• Machine-level variable — the variable must be set as a machine (system) environment variable, for both attended and unattended automations. A user-level variable has no effect; elevation is enabled only when the variable is set at the machine level.

How to enable

1. Open System Properties > Environment Variables on the robot machine.
2. In the System variables section, select New. The variable must be set at the machine (system) level; a user-level variable has no effect.
3. Set the variable name to UIPATH_MEDIUMPLUS_EXECUTOR and the value to 1.
4. Select OK to save the variable.
5. Restart the Robot Service for the change to take effect.

Result

After enabling Medium+ elevation, your automations can interact with the CredentialBroker dialog and other windows that require Medium+ integrity. If UIPATH_MEDIUMPLUS_EXECUTOR is set, the Executor runs elevated for the entire automation; if UIPATH_MEDIUMPLUS_INVOKE is set, only invocations that request elevation run elevated. If the Executor cannot start at the elevated level (for example, because UAC is disabled), it falls back to the default integrity level and logs a warning.