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
- Solutions
- Audit
- Settings
- Cloud robots
- Folders Context
- Automations
- Processes
- Jobs
- Apps
- Triggers
- Logs
- Monitoring
- Queues
- Assets
- Storage Buckets
- Test Suite - Orchestrator
- Resource Catalog Service
- Integrations
- Troubleshooting
Creating an event trigger
Orchestrator User Guide
Last updated Nov 4, 2024
Creating an event trigger
Important: Event triggers that are created at design-time using event 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 event triggers to find out more.
To configure event triggers in Integration Service, read the Configuring event triggers section.
To configure event triggers at process-creation time, in Orchestrator:
Note:
Execution-based trigger disabling
This applies only to event triggers published from Studio Web to personal workspaces.
By default, triggers are disabled after 5 consecutive failed executions. You can
choose to change this setting with the help of the following tenant-level execution
settings:
-
Triggers - Connected triggers - Disable when job execution fail count
-
Triggers - Connected triggers - Grace period when job execution keeps failing count (days)