13.1 Unattended Job Execution: Folders, Priorities, Background vs. Foreground & Runtimes
Key Takeaways
Unattended jobs start from the Jobs or Processes page or from time, queue, event, and API triggers, and run in a folder with a process, an account, and a machine template.
There are ten job priorities; a free robot receives the highest-priority pending job, oldest first on ties, and triggers and manual jobs default to the Inherited process priority.
The API maps priorities to values 1 to 100 through SpecificPriorityValue, for example Critical is 91 to 100.
Background processes can run concurrently, but one account runs only one foreground process at a time on a machine.
Runtimes on a machine template set how many unattended jobs each connected host can run at once; without free runtimes, jobs stay Pending.
13.1 Unattended Job Execution: Folders, Priorities, Background vs. Foreground & Runtimes
Core Concept: The exam description lists "Unattended automations features: Folders, job priorities, background vs foreground processes, license per machine". This section explains how Orchestrator decides which job runs next, on which account and machine, and how many jobs a machine can run at once.
What a Job Is
A job is one execution of a process on a robot. Unattended jobs are launched from Orchestrator, either directly from the Jobs or Processes page or through triggers (time, queue, event, or API). Attended robots cannot run jobs started from Orchestrator, except for debugging and development.
Job States
| Group | States | Meaning |
|---|---|---|
| Initial | Pending | Waiting for a robot or for a connection to it |
| Active | Running, Stopping, Terminating | Stopping follows Stop (a graceful end the workflow can honor with the Should Stop activity); Terminating follows Kill |
| Intermediate | Suspended, Resumed | Long-running workflows waiting for a task, job, or queue item |
| Completion | Successful, Faulted, Stopped | Faulted jobs failed to start or threw an unhandled error; they must be restarted manually |
A job ended with Stop finishes as Successful, while a job ended with Kill finishes as Stopped.
Folders and the Execution Target
A process, its jobs, and its triggers live in a folder. For a job to run, the folder needs:
- The process (a package version deployed to the folder).
- An account (user or robot account) assigned to the folder with unattended settings.
- A machine template assigned to the folder, with runtimes, and a host machine connected with that template.
When starting a job you choose the execution target:
| Option | Behavior |
|---|---|
| Allocate dynamically | Orchestrator picks any account and machine that becomes available. A process can be run up to 10,000 times in one job request this way. |
| Account | Runs under the chosen account; the machine is picked dynamically. |
| Machine | Runs on a host of the chosen machine template (optionally a specific Hostname); the account is picked dynamically. |
| Account-machine mappings | Runs on specific account-machine pairs, one pending job per pair (requires the tenant setting that enables account-machine mapping). |
For foreground jobs, each account must also exist as a Windows user on the host machines connected through the template.
Job Priorities
A job can have one of ten priorities. From lowest to highest: Lowest, Very low, Low, Medium-low, Medium, Medium-high, High, Very high, Highest, Critical.
How Orchestrator allocates pending jobs
- A robot becomes available.
- Orchestrator identifies that robot's machine template and every folder the template is assigned to.
- It evaluates the pending jobs from those folders.
- It gives the robot the job with the highest priority. Jobs with the same priority go out oldest first.
Where the priority comes from
- The process has a priority.
- Jobs started manually and triggers default to Inherited, meaning they use the process priority.
- A trigger with its own priority passes that priority to the jobs it launches.
The API view: 100 levels
The ten UI levels map to 100 API values through the SpecificPriorityValue parameter (for example on StartJobs and ProcessSchedules):
| Priority | API range | Default |
|---|---|---|
| Lowest | 1–10 | 5 |
| Low | 21–30 | 25 |
| Medium | 41–50 | 45 |
| High | 61–70 | 65 |
| Critical | 91–100 | 95 |
Two jobs with values 92 and 94 are both Critical, but the job with 94 runs first.
Background Versus Foreground Processes
| Background process | Foreground process | |
|---|---|---|
| User interface | Needs no UI interaction (APIs, files, data) | Needs UI interaction (User interaction: Required on the Jobs page) |
| Concurrency on one machine | Several can run at the same time, even under the same account, as long as runtimes are available | One account can run only one foreground process at a time on a machine |
| Session | Runs in the robot service's context | Needs an interactive Windows session for the account |
| Typical use | Dispatchers, API integrations, data processing | Desktop and web UI automation |
On a machine template you can also restrict the process type the machine accepts: foreground only, background only, or all.
License per Machine: Runtimes
Unattended capacity is expressed as runtimes allocated to a machine template. Each runtime allows one concurrent unattended job on each host machine connected with that template. For example, a template with 2 unattended runtimes lets every connected host run up to two jobs at once, which on a Windows Server host with several accounts means two sessions in parallel. Without free runtimes, new jobs stay Pending.
Keeping Jobs Healthy
- Schedule ending of job execution: stop or kill a job that stays Pending or Running too long.
- Keep account-machine allocation on job resumption: by default a resumed long-running job can continue on any available robot; this option keeps the original pair.
- Robot reconnects: if a machine goes down or the robot service crashes during execution, the robot restarts its running jobs after reconnecting.
Two pending jobs in the same folder wait for the only free robot. Job A has priority High and was created at 09:00. Job B has priority Critical and was created at 09:05. Which runs first?
Job A, because Orchestrator always runs the oldest job first.
Both start together on the same robot.
Job B, because Orchestrator gives the available robot the pending job with the highest priority, and uses age only to break ties.
Whichever job was started by a trigger.
A process is started through the API with SpecificPriorityValue 94, and another with 92. What is true?
Both are Critical priority, and the job with value 94 runs before the job with value 92.
Values above 10 are invalid because there are only ten priority levels.
Both are High priority and run in creation order.
The API value is ignored; only the process priority counts.
One robot account on one machine is running a foreground process. A second foreground job and a background job are pending for the same account and machine, and the template has enough runtimes. What happens?
Both pending jobs start immediately in the same session.
The background job can run concurrently, but the second foreground job waits, because an account can run only one foreground process at a time on a machine.
Both jobs fail because the account is busy.
The foreground job starts and the background job waits.
Sections you finish are checked off in the contents.