Creating a queue trigger

Important:

Queue triggers that are created at design-time using queue trigger activities can be further configured at process-creation time, in Orchestrator, as these types of triggers are identified as package requirements. Read Managing package requirements > Adding time and queue triggers to find out more.

You cannot create queue triggers for processes that already contain a queue trigger activity.

Queue triggers and SLA predictions are interdependent in terms of queue-process association. So whenever configuring one, the other is prefilled such as to have parity between the configurations. Say I define a queue trigger for queue Y to use process X. SLA predictions for queue Y can only be made using process X, therefore X is prefilled and read-only when enabling queue SLA for Y.

In a folder, navigate to Automations > Triggers and on the Queue Triggers page, click Add a new trigger. The Create Queue Trigger page is displayed.
From the Process Name drop-down menu, select the process you want to configure a time trigger for.
The Name field is prepopulated with the process name, followed by the trigger type in the format <ProcessName>_<TriggerType>. However, the trigger name can be edited with a different name, if preferred.
From the Job Priority drop-down menu, select the priority of the job. The default value is Inherited, meaning that the job priority is the same as the one defined for the selected process.
From the Runtime type drop-down menu, select the runtime license type.

On the Execution Target tab, select your jobs' allocation mechanism and execution target.

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

Note: A warning is displayed upon selecting a hostname that is not active (i.e, with the Unresponsive or Disconnected status). Jobs scheduled to be executed by the inactive session remain in a Pending state until the corresponding connection to Orchestrator is made.

To acknowledge your selection of the inactive hostname, click Confirm.

To go back and make another Hostname selection or none (i.e, the first available machine in the template pool gets selected), click Cancel.

Configuring the same trigger with the same account-machine mapping, but with the additional hostname selection doubles the number of jobs to be executed.

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.

On the Arguments tab, provide values for input arguments if your process has any. More details about input and output arguments.
Select the queue used to trigger the execution.

Set the configuration parameters described in this table.

Description
Minimum number of items that trigger the first job	The item-processing job is only started after the targeted queue has at least this number of new items. Deferred queue items are not counted.
Maximum number of pending and running jobs allowed simultaneously	The maximum number of allowed pending and running jobs, counted together. For 2 or more jobs allowed simultaneously, the third option needs to be defined as described below.
Another job is triggered for each __ new item(s)	The number of new queue items (on top of the number configured for the Minimum number of items that trigger the first job option) to trigger a new job.
After completing jobs, reassess conditions and start new jobs if possible	If selected, the queue trigger is evaluated after each job completion, and new jobs are started if robots are available. This complements the automatic check that occurs every 30 minutes, and helps ensure that remaining queue items are processed with no lags when possible.

From the Timezone drop-down menu, select the time zone according to which the queue trigger gets disabled (see step 13).
From the Non-working days restrictions drop-down menu, select a non-working days calendar if you want your trigger to stop firing on certain non-business days. More details about non-working days.
Turn on the Schedule ending of job execution toggle to select a job termination strategy.
Note:
- The amount of time specified here elapses according to the specifications, even if the job is queued. For example, if you schedule a job to run at 1 p.m. and set it to stop after 20 minutes, the job stops at 1:20 p.m. even if it had stayed in a queue until 1:15 p.m., and then started.
- The Schedule ending of job execution options of a trigger are preserved for manually started jobs.
For example, say you created the trigger T1 and you activated the following job ending schedules:
- Schedule ending of job execution:Stop a job after 10 mins
- Schedule automatic "Kill", if the job does not stop:Kill job after 2 mins
  
  On the Automations > Triggers page, when you click Start a Job Now for the trigger T1, the Start Job page opens with the job ending schedules already applied, the same ones you configured when you created the trigger.
Example: If you schedule to stop a Pending or Running job after 2 hours and also configure to kill the same job after 3 hours, the job will be killed after 5 hours. This happens because, first, the signal is sent to Orchestrator that the job was indeed stopped after 2 hours. Once the signal has been received, the kill job action is triggered to occur in 3 hours, thus resulting a total of 5 hours.
- Select Stop from the drop-down - attempts to gracefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes);
  Example: Orchestrator will attempt to stop jobs that have been stuck for at least 10 minutes in Pending or Running.
- Select Kill from the drop-down - attempts to forcefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running state (set the time to a minimum of 1 minute, maximum of 10 days, 23 hours and 59 minutes);
  
  Example: Orchestrator will attempt to kill jobs that have been stuck for at least 10 minutes in Pending or Running.
- Select Stop from the drop-down and enable the If the job does not stop, kill it option - attempts to gracefully end the execution after the defined time interval has passed since the job is stuck in a Pending or Running 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).
  
  Example: Orchestrator will attempt to stop jobs that have been stuck in Pending or Running for at least 10 minutes. If the termination does not happen, Orchestrator will attempt killing those jobs that have been Stopping for at least 20 minutes.
Enable the Schedule automatic trigger disabling toggle, and enter the date and time when the trigger is to be disabled. The selected time zone selected influences when the queue trigger gets disabled.
Turn on the Generate an alert if the job is stuck (in pending or resumed status) toggle, and set the acceptable duration for the job to remain in the pending or resumed status. The minimum configurable duration is one minute. The maximum configurable duration is 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.
Turn on the Generate an alert if the job started and has not completed toggle, and set the acceptable duration for the job to complete. 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 pending 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.

Turn on the Set execution-based trigger disabling toggle if you would like to control when the trigger is disabled once a job fails. This toggle reveals two options:

Option	Description
Disable when consecutive job execution fail count	The trigger is disabled after the number of failed executions you choose for this setting. You can choose a value between 0 and 100. The default is 0, meaning that the trigger is never disabled. Stopped jobs are not counted towards this value.
Grace period on disabling the trigger (days)	The number of days to wait before the trigger is disabled after the first failure of a job. You can choose a value between 0 and 30. The default is 0, meaning that the trigger is disabled as soon as the job fails, with no waiting time.

To keep the same account-machine context configured for starting the job, check the Keep Account/Machine allocation on job resumption box. This optimizes your license and resource usage.

Was this page helpful?

PREVIOUSCreating a time trigger

NEXTCreating an event trigger

Support and Services

Get The Help You Need

UiPath Academy

Learning RPA - Automation Courses

UiPath Forum

UiPath Community Forum

Trust and Security

Cookies Policy