We use triggers quite often which have slightly different inputs (robots / process / process parameters) both in development and production orchestrators. Similarly we also create multiple queues for a single process. A clone feature for queues also could make this easier. The queue properties will also require minimal change from the users.
Currently, hamburger menu on a trigger shows the following options.
Currently, hamburger menu on queue shows the following options.
A cloned trigger needs to be in disabled state to avoid unintended job runs and contain a suffix to the name to ensure no clashes occur with the original trigger. The cloned queue name can also have a suffix.
Could you clarify how you would see the experience.
If I got it right, you would like the “duplicate” button for a trigger that would duplicate both the trigger and the underlying queue (if it is a queue trigger). And you would also like to have a separate “duplicate” button for the queue itself, one that would only duplicate the queue but without the trigger. Is my thinking correct and in line with what you are proposing?
TLDR Process 1 — Consumes Queue 1 — Triggered by Trigger 1
User navigates to Queue 1 and clicks the hamburger menu and chooses to clone queue, which generates Clone Queue 1 and retains queue properties. User renames the queue as necessary.
User navigates to Triggers and clones the corresponding trigger, which generates a Clone Trigger 1. User renames the trigger and changes the schedule conditions as needed.
Repeat 1, 2 N number of times to scale up the automation.
Background
This suggestion was after our expierence with scaling automations in On-Premises Orchestrator.
We usually work with processes where we develop one single process (REFramework) which takes input arguments.
For example, the input arguments can be QueueName and LocationName (process runs for each location and can range from 4 to 10 locations). Sometimes, these process run on dedicated VM and other times they use advanced triggers to not clash with other production processes.
Painpoint
So when we try to scale the process to multiple locations, each location will have its dedicated QueueName and will run its own trigger (Cron expression). The burden on the deployment will decrease if
We can clone Queues (without the need to retain the queue items, but only retain its properties, for example number of retries)
We can easily clone Triggers it will save a lot of time trying to setup them up for each new location. The trigger clone might not be as time saving as cloning the queue as the trigger conditions and VM running the automations can be dynamic.
Both cloning of a queue and cloning of a trigger are not dependent on each other. They are independent events.
