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.

1. 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.
2. From the Process Name drop-down menu, select the process you want to configure a time trigger for.
3. 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.
4. 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.
5. From the Runtime type drop-down menu, select the runtime license type.
6. 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.

7. On the Arguments tab, provide values for input arguments if your process has any. More details about input and output arguments.
8. Select the queue used to trigger the execution.
9. Set the configuration parameters described in this table.

   	Description
   Minimum number of items to 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).	A new job is triggered for each number of new items added on top of the number of items defined for the first option. Only enabled if there are 2 or more jobs allowed simultaneously (defined using the option described above).
   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.

10. From the Timezone drop-down menu, select the time zone according to which the queue trigger gets disabled (see step 13).
11. 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.
12. 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.

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

      

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

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

13. 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.
14. 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.
15. 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.
16. 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.

    Note:

    If you choose a Cloud - Serverless runtime for the underlying process, the Set execution-based trigger disabling option is automatically enabled, with the following default values (the fields are read-only):

    • Disable when consecutive job execution fail count is set to 10.

    • Grace period on disabling the trigger (days) is set to 0.

    This only applies to you if you are on the Community licensing plan.

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