- 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
- 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
- Managing your host license
- Configuring system email notifications
- Audit logs for the host portal
- Maintenance Mode
- Organization administration
- Troubleshooting
Time triggers
Trigger time zones: The time zone set on a trigger is not restricted by the time zone of the tenant. However, if you use non-working days calendars, you cannot set different time zones.
Time triggers are launched according to the time zone defined on the trigger level.
Time triggers are disabled based on the trigger time zone.
Time triggers configured for recurrent execution take into account the second of their creation time. This is how the change translates in cron expressions:
-
For a time trigger created at 12:23:34 with the cron expression 0 * * ? * * (i.e. set to run every minute), the next execution time will be at 12:24:34.
-
For a time trigger created at 12:23:34 with the cron expression 1 * * ? * * (i.e. set to run at 1 second past every minute), the next execution time will be at 12:24:01.
By default, when a trigger experiences 10 consecutive failed launches and hasn't successfully launched in the past 24 hours, it is automatically disabled. However, if either of those conditions is not met, such as the trigger successfully launches at least once in the day, or it doesn't reach 10 consecutive failures, it stays active.
This value can be customized using the Triggers.DisableWhenFailedCount parameter.
Recommendations
-
When a trigger is disabled, check the audit logs for job failure reasons.
-
If you have long-running jobs, try setting the trigger in such a way as to allow more pending jobs or try scheduling the trigger to run less often.
You can configure several rules depending on which the associated processes get executed.
|
Description | |
|---|---|
|
Dynamic Allocation |
Allocate Dynamically Define how many times a process is to be executed according to the given trigger. 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 trigger. |
|
Account The process is executed under a specific account. Specifying only the account results in Orchestrator allocating the machine dynamically. Specifying both the account and the machine template means the job launches on that very account-machine pair. | |
|
Machine The process is executed on one of the host machines attached to the selected machine template. Specifying only the machine template results in Orchestrator allocating the account dynamically. Specifying both the account and the machine template means the job launches on that very account-machine pair. Note: Make sure the required runtime licenses to execute the job are allocated to the associated machine template.
| |
|
Hostname After selecting a machine template, the Hostname option is displayed, allowing you to select the desired workstation/robot session to execute the process. All available sessions in the active folder are displayed, either unconnected, disconnected, or connected. Note: Only unattended runtimes can be used to configure the mapping. Make sure the required runtime licenses to execute the job
are allocated to the associated machine template.
| |
|
Select valid account-machine mappings |
The process can be executed on multiple specific account-machine pairs. Learn more about account-machine mappings. Note:
|
-
To acknowledge your selection of the inactive hostname, click Confirm.
-
To go back and select another hostname, click Cancel.
-
For example, say you configured a trigger T1 with the account A1 mapped to the machine template MT1. A number of ten jobs are queued in this configuration.
Later on, you configure the same trigger T1 with the account A1 mapped to the machine template MT1, but now you also select a hostname H1. The same ten jobs are queued again for this case, as Orchestrator interprets the configuration as new.
- If you set multiple triggers 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.
-
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 trigger:
-
The second trigger is processed.
- If this execution finishes before the 11:25 trigger, the latter is also executed.
- If the execution of the 11:21 trigger 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 trigger:
-
The 11:21 trigger is placed in a queue, in a pending state.
- If the execution of the 11:21 trigger finishes before the 11:25 one, the latter is also executed.
- If the execution of the 11:21 trigger starts but does not finish before the 11:25 one, the last trigger is placed in a queue, in a pending state.
- If the 11:21 trigger 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.
-
-
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.
Let's say you want to run a process 7 times. The moment your trigger 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.
-
If two or more triggers 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: trigger A runs a process 13 times and trigger 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 many jobs from A are in progress or have been executed. Say 6 jobs have been executed. When B triggers, 13 jobs are added, such that the maximum of 20 has been reached.
-
If a trigger runs the same process multiple times, the related queued jobs are limited to the number of executions specified when you defined the trigger, on the Execute Target tab. They do not cumulate with each launch of the trigger.
Let's say that every 30 minutes you want to run the same process 10 times. The first time your trigger is launched 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.
Time triggers can also be created by RPA developers at design-time in Studio, using the Time Trigger activity of the UiPath.Core.Activities package.
Orchestrator identifies these types of triggers as package requirements, and the only way to add them in Orchestrator is from the Package Requirements page.
Any configuration set at design-time is reflected in Orchestrator and cannot be modified.
For example: Every working day, at 6:00p.m., I want to automatically upload all new Excel files to a cloud drive. The difference here is that the time trigger instructs the automation to start from the inside of the workflow, as opposed to Orchestrator time triggers, which instructs the automation to start from the outside of the workflow.
