- 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
- Configuring automation capabilities
- Audit
- Resource Catalog Service
- Automation Suite robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Integrations
- Troubleshooting
About triggers
Triggers enable you to execute jobs in a preplanned manner. The Triggers page enables you to create new triggers, manage existing ones, or instantly launch a job based on an existing process.
- Time triggers - they instruct the automation to start at regular intervals. Read more...
- Queue triggers - they instruct the automation to start whenever new items are added to your queues. Read more...
- Event triggers - they instruct the automation to start whenever a specified event occurs (event triggers). Read more...
- API triggers - they allow you to start a job in an external application.
- Outside the workflow - created by folder admins in Orchestrator (time and queue triggers).
- Outside the workflow - created by folder admins in Orchestrator (time and queue triggers), or in Integration Service (event triggers).
- Inside the workflow - created at design-time by RPA developers, using trigger activities.
- Only one trigger activity per workflow is allowed.
- Triggers created at design-time in Studio are the only trigger types that Orchestrator validates as package requirements. They only work when they are added at process-creation time, from the Package Requirements page.
This enables you to define multiple lists of non-business days, per tenant, each with its own set of dates, on which you can configure your triggers 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 triggers can be configured such that they don't get launched. You can define or upload such calendars on the Non-Working Days tab, in the Settings page. A BankHoliday calendar is created by default, to help you define your first non-working days easier. Once the non-business days defined in the selected calendar are over, the trigger is launched as usual.
In order to apply any of these restrictions to your triggers, you need to select the desired calendar from the Non-working day restrictions drop-down when creating a new trigger or editing an existing one. You can select only one calendar for a trigger. Note that editing a calendar on the Non-Working Days tab also affects triggers that already have that calendar selected within the Non-working day restrictions drop-down.
For more details on how to manage non-working days, click here.
Note that adding and removing non-working days is audited at the tenant level. More details about audit here.
The Triggers.JobsCountStrategy parameter enables you to choose the strategy for launching jobs through triggers. The following options are available:
PerProcess- A trigger launches the required number of jobs taking into account any pending jobs for the specified process. E.g., two triggers defined for the same process launch 3 and 5 jobs, respectively. If the first trigger launches 3 jobs at a given point in time, when the second trigger is set off, 2 jobs are launched so as to reach the 5 required jobs.PerTrigger- A trigger launches the required number of jobs taking into account any existing jobs previously launched by that same trigger. E.g., a trigger is defined to launch 9 jobs at a given point in time. If 2 jobs have been successfully completed by the time this trigger is set off again, Orchestrator launches another 2 jobs so as to reach the 9 required jobs.NoLimit- The trigger launches the required number of jobs irrespective of any existing, pending jobs. E.g., a trigger is defined to launch 5 jobs at a given point in time. The second time the trigger is set off, another 5 jobs are launched.
