- 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
- SmartCard Authentication
- Audit
- Settings - Tenant Level
- Resource Catalog Service
- Automation Suite robots
- Folders Context
- Automations
- Processes
- Jobs
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Integrations
- Classic Robots
- Troubleshooting
Managing Jobs
Before going through the steps below, you need to create a process.
- Navigate to Automations > Jobs from the folder that the process resides in.
- Click Start. The Start Job window is displayed.
- From the Process Name drop-down, select a process that has been previously deployed to the current folder.
- Configure the required fields, as outlined in the sections below.
- Click Start. The Start Job window closes and, if there are available runtimes on the currently active folder, the job starts on a Robot according to the settings you made. The State of the job is displayed in real-time on the Jobs page.
Setting the job priority
From the Jobs Priority drop-down, select the priority of the job to be executed, if you want it to be different from the priority set at the process level. This field is automatically populated with the priority inherited from the package.
Selecting the execution runtime
From the Runtime type drop-down, select the runtime type used to execute the job.
The number of available and connected runtimes is displayed below the drop-down.
- _ Available - The number of available runtimes, calculated as the total number of runtimes minus the number of running jobs.
-
_ Connected - The total number of runtimes, calculated as the sum of runtimes on all machines connected to Orchestrator that is associated with the active folder.
Runtime type
Description
Production (Unattended)
The job is executed in unattended mode consuming an Unattended runtime.
Testing
The job is executed in unattended mode consuming a Testing runtime.
NonProduction
The job is executed in unattended mode consuming a NonProduction runtime.
Cloud - Serverless Testing
The job is executed in unattended mode, on a serverless robot machine that was configured to run in a testing environment. The amount of required robot units is specific to testing environments and depends on the size of the serverless robot machine and the number of minutes it takes to execute a job.
See Robot units - Consumption for more details.
Cloud - Serverless
The job is executed in unattended mode, on a serverless robot machine that was configured to run in a production environment. The amount of required robot units is specific to production environments and depends on the size of the serverless robot machine and the number of minutes it takes to execute a job.
See Robot units - Consumption for more details.
Cloud - VM Testing
The job is executed in unattended mode, on a cloud VM that was configured to run in a testing or non-production environment. Running the VM consumes the robot units for testing environments.
See Robot units - Consumption for more details.
Cloud - VM
The job is executed in unattended mode, on a cloud VM that was configured to run in a production environment. Running the VM consumes the robot units for production environments.
See Robot units - Consumption for more details.
Example: Say you have 2 NonProduction runtimes and 1 Unattended runtime on machine template A, and 3 NonProduction runtimes, and 2 Unattended runtimes on machine template B. Both are associated with one folder. On each template, you connect one host machine. The resulting runtime state is the following:
- Unattended:
3 Available, 3 Connected - NonProduction:
5 Available, 5 Connected
A running job occupying a runtime subtracts 1 from the number of available runtimes for that type.
At publish time, Orchestrator chooses from the available personal workspace runtimes to execute the job. The runtime precedence is the following:
- Serverless (only available for Orchestrator in Automation Suite)
- Production (Unattended)
- Nonproduction
For example, if no Serverless runtimes exist in your personal workspace, Orchestrator uses an available Production runtime. If that doesn't exist either, Orchestrator uses an available NonProduction runtime. If none exists, the job fails.
If the selected runtime becomes unavailable between job executions, the upcoming job execution fails, since Orchestrator does not look for the next available one.
Configuring the execution target
Configure your execution target by setting the options below as desired on the Execution Target tab.
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 this option you can execute a process up to 10000 times in one job.
Account
You can choose one of these approaches:
- Specifying an account means the process is executed under that specific user or robot account.
- Specifying both the account and the machine means the job launches on that very account-machine pair. Only valid account-machine pairs are available for selection.
- Specifying no account results in Orchestrator allocating the account dynamically.
Machine
You can choose one of these approaches:
- Specifying a machine object means the process is executed on one of the host machines attached to the selected machine template. Select a specific host machine from the pool of connected host machines on the Connected Machines field.
- Specifying both the account and the machine means the job launches on that very account-machine pair. Only valid account-machine pairs are available for selection.
- Specifying no machine results in Orchestrator allocating the host machine dynamically.
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.
Select valid account - machine mappings
Keep Account/Machine allocation on job resumption
This field allows you to configure whether the different fragments of a long-running job are executed on the same account-machine pair.
By default, a suspended job is resumed on any available robot on any available machine.
Based on your license or resource requirements, you have the option to resume a job on the same machine and in the same account context that started the job.
Say you need an SAP license to execute a job. Instead of installing an SAP license on every available machine (increased costs), you can install it on a single machine and use that machine to start and resume the job. The same strategy may apply to user licenses. You can allocate only one user license and use it to execute the job.
Schedule ending of job execution
The process execution may sometimes be faulty, causing the job to remain in the pending state. Turning on the toggle allows you to (click to expand):
- Select Stop from the drop-down menu - this attempts to gracefully end the execution after the defined time interval has passed since
the job is stuck in a pending state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes).
- Select Kill from the drop-down menu - this attempts to forcefully end the execution after the defined time interval has passed since
the job is stuck in a pending state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes).
- Select Stop from the drop-down menu and turn on the Schedule automatic "Kill", if the job does not stop option - this attempts to gracefully end the execution after the defined time interval has passed since the job is stuck
in a pending state and then attempts to forcefully end it after the defined time interval has passed since the job is stuck
in a stopping state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes).
Generate an alert if the job is stuck in pending or resumed status
By turning on the toggle, you activate alerts about jobs that remain in the pending or resumed status longer than the specified duration.
The configurable duration is minimum one minute and maximum eleven days.
If the job exceeds the configured duration, an "Error" severity alert pop-up informs you about it with the following text:
"N jobs for #process {process_number} have been pending or resumed for more than X hours and Y minutes.", where:
- N - is the number of jobs that triggered the alert
- {process_number} - the process identifier
-
X - the configured number of hours the job exceeded while having the pending or resumed status. Days are converted to hours.
- Y - the configured number of minutes the job exceeded while having the pending or resumed status.
Generate an alert if the job started and has not completed
By turning on the toggle, you activate alerts about jobs that do not complete in the specified duration.
The configurable duration is minimum one minute and maximum eleven days.
If the job exceeds the configured duration, an "Error" severity alert pop-up informs you about it with the following text:
"Job for #process {process_number} has been running for more than X hours and Y minutes.", where:
- {process_number} - the process identifier
-
X - the configured number of hours the job exceeded while trying to complete. Days are converted to hours.
- Y - the configured number of minutes the job exceeded while trying to complete.
Orchestrator prevents starting jobs on invalid configurations. Trying to start a job in an invalid setup results in a descriptive error message providing you with details about how to fix your configuration.
Starting a job using dynamic allocation, i.e. no machine or account specified, with an incompatible folder setup results in an error. Make sure to correct the setup, otherwise, jobs stay pending indefinitely. For example, trying to run a .NET Framework 4.6.1 background job when there are only cross-platform templates in the folder does not work, as jobs stay pending until the configuration is fixed.
Adding arguments
On the Arguments tab, provide input arguments for the selected process. This tab is automatically populated with all the input arguments accepted by the selected process, and the corresponding values inherited from the package.
Click the corresponding More Actions button, and then Stop. The automation project is executed until it finds a Should Stop activity. During this time, the job is in the Stopping state. If the activity is encountered, the execution is stopped, and the job's final status is Successful. If a Should Stop activity is not found, the job execution does not stop until it reaches the end of the project. The final status, in this case, is Successful as well.
- A job started from Orchestrator can be stopped only from Orchestrator.
- A job started from the Assistant can be stopped both in Orchestrator, from the Jobs page, and using the UiPath® Assistant.
- Once a job has been stopped, the job ending schedules are lost and you need to reconfigure Schedule ending of job execution options at job restart.
Click the corresponding More Actions button, and then Kill. The automation project is forcefully stopped, the job is marked as Stopped, and "Job canceled" is displayed in the Job Details window.
- A job started from Orchestrator can be killed both in Orchestrator, from the Jobs page, and using the UiPath Assistant.
- A job started from the Assistant can be killed both in Orchestrator, from the Jobs page, and using the UiPath Assistant.
- Once a job has been killed, the job ending schedules are lost and you need to reconfigure Schedule ending of job execution options at job restart.
This feature enables you to quickly run a job from the jobs list, without going through the configuring job flow. You can restart any job with a final state – Stopped, Faulted or Successful.
- You cannot restart jobs triggered by agents such as the Assistant or through Studio remote debugging sessions.
- When you restart a job that had Schedule ending of job execution options active, you need to reconfigure these options.
This procedure starts from the presumption that you previously started a job that already reached a final status.
- Click the corresponding More Actions button, and then Restart. The Start Job window is displayed, with the job's initial settings.
- Make the desired changes.
- Click Start. The Start Jobs window closes and the execution starts. The status of each job is displayed, in real-time, on the Jobs page.
To view the logs for a specific job, click the corresponding More Actions button, and then View Logs. The Logs page is displayed and contains data regarding the indicated job.
To view details about a specific job, click the corresponding View Details button. This displays the Job Details window, where you can find various information such as:
- the name of the underlying process
- the executing robot and machine
- the reasons behind jobs failing
- the reasons behind the job not starting
- actions you can take to fix any issues and trigger the job to start
Completed job details
Pending job details
To download the recording for a faulted job, click More Options > Download Recording. Execution media is downloaded according to your settings.
