About Jobs

Note: Mastering jobs requires that you first get the hang of processes. Learn about runtime arguments, process types, and process compatibility.

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: <Domain\Username> - jobs executed under that specific account. Displayed in the following cases: foreground jobs regardless of the Robot version; all jobs executed on Robots lower than 2021.10; attended jobs executed on robots connected using a machine key, without user sign-in. 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. ROOT - background jobs executed on Linux robots . NT AUTHORITY\LOCAL SERVICE - jobs executed under the Robot service identity. Displayed for background jobs executed on Robots 2021.10+ without credentials. Service mode robots run under NT AUTHORITY\LOCAL SERVICE. User mode robots run under a certain user identity. N/A - jobs started from the Assistant by users connected using interactive sign-in . For robots connected using the machine key, without user sign-in, the <Domain\Username> is displayed.
Job type	The type of job according to where the execution takes place and depending on whether the robot impersonates a user or not: Service unattended - The execution happens on a server and the robot does not impersonate a user. Jobs are launched from Orchestrator Personal remote - The execution happens on a server and the robot runs under the identity of a personal workspace owner. Jobs are launched from Orchestrator. Attended - The execution happens on a user's personal machine. Jobs are launched from the Assistant. Development - The execution happens on a server. Jobs are launched from Studio through remote debugging.
Runtime type	The runtime type used for execution.
State	The state of the job. See details about job states.
Priority	The priority of the job. See details about job priorities.
Started	The relative amount of time since the job has started executing. Hovering over this field displays the exact start time and date.
Ended	The relative amount of time since the job has finished executing. Hovering over this displays the exact end time and date.
Started (absolute) (*)	The absolute amount of time since the job has started executing. Absolute timestamps are rendered in the tenant time zone. For triggers, the next run time is rendered in the trigger time zone which may differ from the tenant time zone.
Ended (absolute) (*)	The absolute amount of time since the job has finished executing. Absolute timestamps are rendered in the tenant time zone. For triggers, the next run time is rendered in the trigger time zone which may differ from the tenant time zone.
Source	The agent of the execution. Manual - The job was started from Orchestrator. Time trigger - The job was started by a time trigger whose name is displayed in the Source column. Queue trigger - The job was started by a queue trigger whose name is displayed in the Source column. Event trigger - The job was started by an event trigger whose name is displayed in the Source column. API trigger - The job was started by an API trigger whose name is displayed in the Source column. Assistant - The job was started by the UiPath Assistant. Studio - The job was started for debugging purposes from Studio. Apps - The job was started through an app.
Creation Time (*)	The relative time of the job creation.
Creation Time (absolute) (*)	The absolute time of the job creation.

(*) Columns that are not visible in the jobs grid by default. Select them from the Columns dropdown.

Account-Machine Mappings

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. This 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.

Execution Target

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.

Learn about execution targets for triggers.

Note:

If your job execution depends on a specific resource that is not yet available, the job remains in the pending state until the conditions for the jobs execution are met.

For example, user U1 connects to the hostname H1 using credentials C1. However, the wrong credentials C2 are inputted to connect to the hostname. Therefore, the job enters the pending state. If you later update the credentials to the correct ones (that is, C1), the job resumes its execution.

Note: If the Robot becomes unresponsive (the robot machine is down, or the Robot Service crashes) during job execution, after reconnecting, it restarts the execution of the jobs that were running during the crash.

1. Allocate Dynamically

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.

2. Select valid account - machine mappings

You can decide which specific account and machine pairs to run the selected job.

To run multiple jobs at once, one for each pair, click Add Account-Machine mapping and select the desired items from the drop-down lists that are displayed.

Once done, a Pending job is created for each account-machine pair.

Note:

This only works if the Enable user-machine mapping option on the General tab of your tenant settings is selected.

3. Account

The process is executed under a specific user or robot account. Specifying only 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.

4. Machine

The process is executed on one of the host machines attached to the selected machine template. Specifying the template displays an additional Hostname option, allowing you to select a specific host machine from the pool of connected host machines. Specifying only 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.

5. Schedule ending of job execution

The process execution may sometimes be faulty, causing the job to remain in the pending state. The toggle allows you to automate a strategy for stopping the job, by specifying the amount of time that can pass until the job is stopped or killed. To cover the case of a job that cannot be stopped, you have the option to kill the job.

6. Keep account-machine allocation on job resumption

The process resumes itsexecution on any available robot on any available machine by default. To keep the same account-machine configuration ensures an optimized use of resources and license requirements.

Important:

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.

Example

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.

Execution Priority

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 ten priorities:

Starting a Job Manually

The default value for the Job priority field is Inherited, which means that the priority is inherited from where it was initially configured. You can either leave it as it is or change it.

• Where from: Automations Page > Jobs

The job inherits the priority set at the process level.

• Where from: Automations Page > Triggers

If the trigger has the Inherited priority, the job inherits the priority set at the process level.

If the trigger has a priority different to Inherited, the job inherits the priority set at the trigger level. If it is changed to Inherited, the priority set at the process level is used.

• Where from: Automations Page > Processes

The job inherits 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.

Starting a Job Through a Trigger

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.

Any subsequent changes made at the process level are propagated to the trigger, and the jobs created through it implicitly.

Setting the Job Priority using the API

The ten priority levels available in the interface correspond to 100 levels in the API, which means that the API allows you to set an even more granular priority. These levels are mapped as follows:

Minimum	Maximum	Default
Lowest	1	10	5
Very low	11	20	15
Low	21	30	25
Medium-low	31	40	35
Medium	41	50	45
Medium-high	51	60	55
High	61	70	65
Very high	71	80	75
Highest	81	90	85
Critical	91	100	95

To set or change the priority of a job, use the SpecificPriorityValue parameter, which is available in the following endpoints:

• POST​/odata​/Jobs​/UiPath.Server.Configuration.OData.StartJobs
• POST/odata​/ProcessSchedules
• PUT/odata​/ProcessSchedules({key})

Say you have two jobs for which you set a priority of 92 and, respectively, of 94. They both fall within the Critical range, but the job that has a priority of 94 will be executed before the one with a priority of 92.

Note: If you start a job that requires user intervention on multiple Robots on the same machine that does not run on Windows Server, the selected process is only executed by the first Robot while the rest fail. An instance for each of these executions is created and displayed on the Jobs page.

Jobs on High-Density Robots

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.

Recording

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.