- 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
- Audit
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- 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...
-
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 event triggers that are created using trigger activities show up in the Event Triggers grid in Orchestrator.
-
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.
Job execution rules are configured through a number of tenant-level settings, which are detailed in the Execution Settings section of the General tab page.
