orchestrator
latest
false
- 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
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Authentication
- Integrations
- Classic Robots
- Troubleshooting
Creating a queue trigger
Orchestrator User Guide
Creating a queue trigger
Important:
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.
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.