- Getting started
- Best practices
- Tenant
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Other Configurations
- Integrations
- Classic Robots
- Host administration
- About the host level
- Managing system administrators
- Managing tenants
- Configuring system email notifications
- Audit logs for the host portal
- Maintenance Mode
- Organization administration
- Troubleshooting
About Jobs
A job represents the execution of a process on a UiPath Robot. You can launch the execution of a job in either attended or unattended mode. You cannot launch a job from Orchestrator on attended robots, unless for debugging or development purposes.
Attended jobs can be triggered from the UiPath Assistant or the Robot Command Line Interface. Unattended jobs are launched from Orchestrator, either directly on the spot from the Jobs or Processes page, or in a preplanned manner through triggers, on the Triggers page.
The Jobs page represents the jobs control center, where you can monitor launched jobs, view their details and logs, and stop/kill/resume/restart a job.
The table below contains field descriptions for the Jobs page.
|
Field |
Description |
|---|---|
|
Process |
The name of the process. [Remote debugging job] is displayed for jobs started from Studio through
remote debugging
sessions.
|
|
Machine |
The machine object used for connecting the executing infrastructure to Orchestrator. |
|
Hostname |
The name of the workstation used for execution. |
|
Host identity |
The identity under which the execution takes place. The following values are possible:
Note: For Robots older than 2021.10, the host identity gets populated dynamically according to the account settings made in Orchestrator.
Changing the
domain\username for the account used to execute a job changes the host identity as well.
Note:
Service mode robots run under
NT AUTHORITY\LOCAL SERVICE. User mode robots run under a certain user identity.
Known Issue: Filtering by host identity on the Jobs and Logs pages does not work correctly for jobs executed via accounts without credentials. When running jobs on Windows machines, the Host Identity column is populated with the actual identity of the robots (domain\username), however, filtering by this value returns no jobs. When running jobs on Linux machines, jobs are executed under Root, however, this value is not available for filtering. |
|
Job type |
The type of job according to where the execution takes place and depending on whether the robot impersonates a user or not:
|
|
Runtime license |
The runtime type used for execution. |
|
State |
The state of the job. |
|
Priority |
The priority of the job. |
|
Started |
The amount of time since the job has started executing. Hovering over this field displays the exact start time and date. |
|
Ended |
The amount of time since the job has finished executing. Hovering over this displays the exact end time and date. |
|
Source |
The agent of the execution.
|
When starting a job or defining a trigger, you can define specific account-machine pairs on which execution takes place. Account-machine mappings enable you to tie unattended usage under particular accounts to specific machine templates. The gives granular control over the execution targets of your automation. Account-machine mappings can be tenant-based (not tied to a specific folder), or folder-based (tied to a specific folder).
Learn how to configure account-machine mappings.
According to the mechanism used for launching jobs in Orchestrator, you can choose and configure a job allocation strategy and an execution target, implicitly. This article describes the allocation strategies and execution targets available when launching jobs from the Jobs page.
Dynamic allocation with no explicit account and machine selection allows you to execute a foreground process multiple times under the account and machine that become available first. Background processes get executed on any account, regardless if it's busy or not, as long as you have sufficient runtimes.
Using the Allocate Dynamically option you can execute a process up to 10000 times in one job.
The process is executed under a specific user or robot account. Only specifying the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.
The process is executed on one of the host machines attached to the selected machine template. Specifying the template displays an additional Connected Machines option, allowing you to select a specific host machine from the pool of connected host machines. Only specifying the machine results in Orchestrator allocating the account dynamically. Specifying both the account and the machine means the job launches on that very account-machine pair.
Make sure that runtimes matching the job type are allocated to the associated machine template. Only connected host machines associated with the active folder are displayed.
You need to provision a Windows user for each account on a host machine that belongs to the folders to which the corresponding machine template is assigned.
Say you connected a server to Orchestrator using the key generated by the machine template, FinanceT. That machine template is assigned to folders FinanceExecution and FinanceHR, where 6 accounts are assigned as well. Those 6 accounts need to be provisioned as Windows users on the server.
If you configure a job to execute the same process multiple times, a job entry is created for each execution. The jobs are ordered based on their priority and creation time, with higher priority, older jobs being placed first in line. As soon as a robot becomes available, it executes the next job in line. Until then, the jobs remain in a pending state.
Setup
- 1 folder
- 1 machine template with two runtimes
- 2 accounts: john.smith and petri.ota
-
2 processes which require user interaction: P1 - which adds queue items to a queue, P2 - which processes the items in the queue
The machine template and the accounts must be associated to the folder containing the processes.
Desired Outcome
- P1 is executed with a high priority by anyone.
- P2 is executed with a low priority by petri.ota.
Required Job Configuration
- Start a job using P1, don't assign it to any particular account, set the priority to High.
- Start a job for P2, assign it to petri.ota, set the priority to Low.
You can control which job has precedence over other competing jobs through the Job Priority field either when deploying the process or when configuring a job/trigger for that process. A job can have one of the following priorities: Low (↓), Normal (→), High (↑).
The priority is inherited from where it was initially configured. You can either leave it as it is or change it.
If you configure it from the Automations > Jobs page: The job inherits the priority set at the process level.
If you configure it from the Automations > Triggers page: The job inherits the priority set at the trigger level. If the trigger itself inherited the priority at the process level, then that one is used.
If you configure it from the Automations > Processes page: The jobs uses the priority set for that process.
If you configure a job to execute the same process multiple times, a job entry is created for each execution. The jobs are ordered based on their priority and creation time, with higher priority, older jobs being placed first in line. As soon as a robot becomes available, it executes the next job in line. Until then, the jobs remain in a pending state.
The priority is set by default to Inherited, meaning it inherits the value at the process level. Choosing a process automatically updates the arrow icon to illustrate what value has been set at the process level. Any jobs launched by the trigger have the priority set at the trigger level. If the default Inherited is kept, the jobs are launched with the priority at the process level.
If you start a job on multiple High-Density Robots from the same Windows Server machine, it means that the selected process is executed by each specified Robot, at the same time. An instance for each of these executions is created and displayed on the Jobs page.
If you are using High-Density Robots and did not enable RDP on that machine, each time you start a job, the following error is displayed: “A specified logon session does not exist. It may already have been terminated.” To see how to set up your machine for High-Density Robots, please see the About Setting Up Windows Server for High-Density Robots page.
For unattended faulted jobs, if your process had the Enable Recording option switched on, you can download the corresponding execution media to check the last moments of the execution before failure.
The Download Recording option is only displayed on the Jobs window if you have View permissions on Execution Media.
