- Organization Modeling in Orchestrator
- Managing Large Deployments
- Automation Best Practices
- Optimizing Unattended Infrastructure Using Machine Templates
- Organizing Resources With Tags
- Orchestrator Read-only Replica
- Exporting grids in the background
- 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
- Bulk Uploading Queue Items Using a CSV File
- Managing Queues in Orchestrator
- Managing Queues in Studio
- Review Requests
- Test Automation
- Host Administration Portals
- Configuring System Email Notifications
- Managing System Administrators
- Configuring Host Security
- Host Audit Logs
- Customizing the Login Page
- Maintenance Mode
- Managing tags
- Audit Logs
- Overriding System Email Settings
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 for an existing trigger.
Outside the workflow - created by folder admins in Orchestrator (time and queue 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.