- Getting started
- Best practices
- 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
- Registry
- Cloud robots
- Automation Suite Robots
- Folders Context
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Indexes
- Queues
- Assets
- Connections
- Business Rules
- Storage Buckets
- MCP Servers
- Orchestrator testing
- Resource Catalog Service
- Integrations
- Troubleshooting
Feature availability depends on the cloud offering that you use. For details, refer to the Feature availability page.
A process is a deployed and configured state of a package, ready to be executed as a job.
More specifically, a process represents a package version linked to a particular folder. When you deploy a new process, it becomes available for all accounts that have access to that folder.
The Processes page enables you to deploy an uploaded package as a new process, manage previously created processes, keep all your processes up to date with the most recent package versions, and directly start a job using the desired process. This helps you distribute packages across all accounts in your organization and execute processes faster whether from the Processes or Jobs page.
In addition to executing processes from the Processes and Jobs pages, you can also configure any process to automatically start when the Robot agent is launched. As an administrator, this enables you to ensure that necessary processes are launched without delay or failure from the machine user, for example, to ensure adherence to company IT policies.
The following table contains column descriptions for the Processes grid.
| Field | Description |
|---|---|
| Name | The display name of the process. You can sort the processes list by Name . |
| Type | The project type. The following options are available:
|
| Package Name | The name of the package that was deployed. Not visible by default. To display the column, select it from the Columns menu. You can sort the processes list by Package Name . |
| Version | The number of the package version currently being used in a given process.
|
| Job priority | The priority of the job. You can sort and filter the processes list by Job priority . |
| Execution type | The type of the process execution. Linked to the Attended Automation project setting in Studio:
The Unspecified value is displayed for packages published prior to the 2021.10.3 Studio version. |
| User interaction | Specifies whether the process requires user interaction:
|
| Compatibility | The compatible operating system for the underlying target framework of the automation project. |
| Entry point | The workflow file used to start the execution of the process. By default, the Main.xml file is set as the entry point. If your project contains multiple entry points, the one selected at process creation is displayed. When you change the package version during process editing, the selected entry point is preserved if the same workflow exists in the new version. |
| Description | A custom description for the process. It is recommended that you populate this field, especially when dealing with multiple users and processes in Orchestrator. |
| Labels | The list of all labels associated with the process. |
| Properties | The list of all key-value pairs associated with the process. |
| Retention action | The retention policy outcome at the end of the retention duration. |
| Retention (days) | The duration of the retention policy. |
Runtime Arguments
Entry Points
For projects with multiple workflows, use Main.xaml as your main workflow and link other .xaml files through the Invoke Workflow File activity. Learn more about project organization in Studio.
You can change or add entry points to control which workflow executes. In Studio, right-click a .xaml file and set it as main or add it as an entry point.
Example: Multiple invoice processing workflows
You have two workflows to process invoices from different sources:
DownloadInvoiceFromStorage.xaml— downloads the invoice from external storageGetInvoiceFromLocal.xaml— retrieves the invoice from a local device
At runtime in Orchestrator, select the entry point that matches your scenario. If the invoice is already local, select GetInvoiceFromLocal.xaml to start execution from that workflow.
For packages published before July 2020, Orchestrator cannot auto-detect the main entry point. Select the entry point manually from the drop-down. If the process doesn't support multiple entry points, Default is displayed and the field is disabled.
In, Out, In/Out Arguments
Designing your project in Studio to accept In or Out arguments enables you to use them in other third-party apps or Orchestrator. This means that any process you create can receive input arguments through the Orchestrator API or interface.
In Orchestrator, arguments and related information are displayed in multiple places: at the process level, job level, and trigger level in the dedicated arguments sections (Runtime Arguments or Arguments tab).
You can specify values for any input arguments. For more info on input and output arguments in Orchestrator, please visit this page.
Figure 1. Process configuration
Figure 2. Arguments
Default values provided for In arguments in Studio are not displayed in Orchestrator, at any level.
Background Vs Foreground Processes
Processes are classified by their user interface requirements.
Background Processes
Background processes don't require a user interface or user intervention. You can execute multiple background jobs simultaneously on the same user in unattended mode. Each execution requires an Unattended/NonProduction license. Unattended robots run background processes in Session 0 under NT AUTHORITY\LOCAL SERVICE, which has no UI access.
Learn more about background process automation in Studio.
Foreground Processes
Foreground processes require user interface access (either for UI generation or interactive activities like Click). You can execute only one foreground process per user simultaneously. However, the same user can execute multiple background processes and one foreground process at the same time.
Configuring process type
The process type is set in Studio on the Project Settings window and appears in Orchestrator after publishing.
Figure 3. Starting a process in background
The following table shows the UiPath® Robot version required to run foreground/background processes according to the robot credential considerations.
| Process type | Credential considerations | Robot version |
|---|---|---|
| Background | Robot with credentials | Any |
| Foreground | Robot with credentials | Any |
| Background | Robot without credentials | 2021.10+ |
| Foreground | Robot without credentials | Invalid configuration! Jobs cannot be executed. |
Process Compatibility
When creating an automation project in Studio, developers must configure a compatibility attribute that impacts the underlying target framework of the automation project and the compatible operating system.
Figure 4. Process compatibility
The following table shows the UiPath Robot version required to execute processes according to their target frameworks and OS compatibility considerations.
| Target framework | Operating system | Robot version |
|---|---|---|
| .NET Framework 4.6.1 | Windows - Legacy | Any |
| .NET 5.0+ | Windows | 2021.10+ |
| .NET 5.0+ | Cross-platform | 2021.10+ |
Version Management
If a new version of a package is available in Orchestrator (you published a new version from Studio), it is indicated with the
icon next to the process it is part of.
You may update processes to the latest available version individually, on the corresponding View Processes window, or you may update them in bulk, by selecting multiple of them and clicking the global Use Latest button.
If a package version associated with a process is no longer available in the configured NuGet repository, it is indicated with the
icon.
If you are using the latest available version of a package in a specific process, the
icon is displayed next to the process.
Used applications
Windows applications that are used by the underlying Studio package are displayed in the Applications section, as relevant to the selected package version.
If the package uses applications that cannot be identified, an Unknown apps entry is displayed, suffixed by the number of unidentified apps, in parentheses.
If no applications can be retrieved, a No app(s) could be retrieved for this package message is displayed. This is most likely due to one of the following reasons:
- Your Studio version is older than 2023.2.
- Your Studio version is 2023.2, but a governance rule is in place, preventing this information from being logged.
- Your package was uploaded from an external feed. Only packages from internal feeds can provide this information.
- The package does not use any applications.
These details are also displayed in the Show release notes window for each package version.
Processes Permissions
Creating a process:
- View permission on Packages;
- View and Create permissions on Processes.
Starting a job from the Processes page:
- Permissions for creating a process
- Create on Jobs
Read more about roles.