UiPath Orchestrator Guide

About Schedules

Schedules enable you to execute jobs in a preplanned manner, at regular intervals on Robots. Input values for processes which support input and output parameters can be managed at this level as well. You can assign Robots to perform different schedules according to the following options:

  1. All Robots - Schedules are executed by all the Robots in a specific environment.
  2. Specific Robots - Schedules are executed by the Robots selected by the user.
  3. Allocate dynamically - Define how many times a process is to be executed according to the given schedule. This option enables you to utilize your resources to their greatest extent. As soon as a Robot becomes Available, it executes the indicated process according to the provided schedule.

Note

Jobs assigned to specific Robots have execution priority over any job allocated dynamically.

Keep in mind that the execution time of the schedules can be adjusted according to a specific time zone.

Important!

The time zone set on a schedule is not correlated to the time zone of the tenant (set in the Settings page).

The Schedules page enables you to create new schedules. It also displays all previously created schedules, which can be further edited, enabled, or disabled.

You can view the jobs started by a specific schedule on the Jobs window, by selecting More Actions > View jobs. A scheduled job can also be stopped after a custom amount of time with the Stop or Kill options on the Actions tab.

Queued Jobs Scenarios

  1. If you set multiple schedules on the same Robot and their execution time overlaps at least one time, the jobs are queued, in a pending state. The Robot executes the queued jobs in chronological order.
  2. If the same process is scheduled on the same Robot multiple times and their execution time overlaps, only one process is queued, in a pending state. For example, if process A on Robot X is scheduled to run at 11:20, 11:21 and 11:25, the behavior is as follows:
    • at 11:20 the first process is executed.
    • If the first execution finishes before the second schedule:
      • The second schedule is processed.
        • If this execution finishes before the 11:25 schedule, the latter is also executed.
        • If the execution of the 11:21 schedule does not finish before the 11:25 one, the latter is added to a queue, in a pending state.
    • If the first execution does NOT finish before the second schedule:
      • The 11:21 schedule is placed in a queue, in a pending state.
        • If the execution of the 11:21 schedule finishes before the 11:25 one, the latter is also executed.
        • If the execution of the 11:21 schedule starts but does not finish before the 11:25 one, the last schedule is placed in a queue, in a pending state.
        • If the 11:21 schedule is still in pending when the 11:25 one should start, the latter is no longer executed or added to a queue and the following message is displayed: The Robots already have pending jobs for this process.

Important!

If the connection to the SQL database is lost for any reason, the schedules that were supposed to be triggered at that point are misfired, and an alert with the Error level is generated.

  1. If you want to execute a process multiple times on any Robots that are available, you have the possibility to do just that by using the Allocate Dynamically option on the Execute Target tab. The jobs are queued, in a pending state, in the corresponding environment and each time a Robot becomes available, the first job in line is executed. In this way no Robot is ever available while there are jobs pending.

Note

Using the Allocate Dynamically option you can execute a process up to 10000 times in one job.

Let's say you want to run a process 7 times. The moment your schedule is triggered, 7 pending jobs are added to the environment workload, without being assigned to specific Robots. There are a couple of scenarios possible:

  • There are at least 7 Robots available at trigger time - one Robot gets assigned one job such that all jobs are executed in one go.
  • There are less than 7 Robots available at trigger time, say 4 - each of the 4 Robots gets assigned one job, if a new Robot or one of the 4 becomes available, then it takes over another job of the remaining 3. This happens for each available Robot until no jobs are left.
  1. If two or more schedules are running the same process, each for a different number of times, at the next trigger, the maximum number of jobs between them is added to the environment workload; they do not cumulate. Imagine the following situation: schedule A runs a process 13 times and schedule B runs it 20 times. The following scenarios may arise:
    • A and B trigger simultaneously - 20 jobs (the maximum between 13 and 20) are queued in the environment workload.
    • B triggers first - 20 jobs are queued.
      • If between B's trigger time and A's trigger time, 7 or more jobs have been executed, say 9 (11 remaining pending jobs), then 13 jobs (the maximum between the 11 and 13) are queued in the environment workload.
      • If between B's trigger time and A's trigger time, less than 7 jobs have been executed, say 5 (15 remaining pending jobs), then no more jobs are queued as there are already more than 13 jobs pending. Also, the following message is displayed: The Robots already have pending jobs for this process.
    • A triggers first - 13 jobs are queued
      • Whenever B triggers during A's execution, a number of up to 20 jobs are added to the environment, depending on how much jobs from A are in progress or have been executed. Say 6 jobs have been executed. When B triggers, 14 jobs are added, such that the maximum of 20 has been reached.
  2. If a schedule runs the same process multiple times, the related queued jobs are limited to the number of executions specified when you defined the schedule, on the Execute Target tab. They do not cumulate with each trigger of the schedule.
    Let's say that every 30 minutes you want to run the same process 10 times. The first time your schedule is triggered 10 jobs are queued. If between triggers, less than 10 jobs have been executed (say 4), at the time of the next trigger only 6 new jobs are queued, as the number of pending jobs for that process can be a maximum of 10.

Note

Keep in mind that jobs directly assigned to specific Robots have priority over jobs allocated dynamically. Also, if a Robot is part of two or more environments, jobs are executed in the order they were created.

Non-Working Days

This enables you to define a list of non-business days, per tenant, on which you can configure your schedules to not run if needed. This means that, during public holidays, weekends or any other day on which normal business activities are not being carried out, your long-run schedules can be configured such that they don't trigger. You can define such days on the Non-Working Days tab in Settings page. Once the defined non-business days are over, the schedule triggers as usual.

In order to apply these restrictions to your schedules you need to enable the Apply non-working day restrictions option when creating a new schedule or editing an existing one. Note that every change you make on the Non-Working Days tab will also affect schedules which already have the Apply non-working day restrictions option enabled.

Note

The Apply non-working day restrictions option is disabled for schedules with a timezone different than the timezone set at tenant level (Settings page > General tab). A tenant without an explicitly defined timezone inherits it from the host.

For more details on how to manage non-working days, click here.

Note that adding and removing non-working days is audited at tenant level. More details about audit here.

Disabling a Schedule

If you want your schedule to get automatically disabled at a specific date and time in the future you can do just that by enabling the Disable Schedule at option when creating a new schedule or editing an existing one.

For more details on how to configure your schedules to get automatically disabled, click here.