Feature Request - Assign Multiple Robots to Trigger

Feedback Orchestrator
, ,
1

When setting up a trigger, you can define which robots/machines have access to run jobs generated by that trigger.
image

The problem is, the only options are A) Any robot, or B) exactly one specific robot. It would be better if this field allowed you to multi-select a particular set of robots, to form a pool of that is enabled for a particular process.

Consider the following use case:

I have one machine, a terminal server configured for high density robots. The machine has five robots assigned, and five unattended runtimes. I have six processes in production, one of which is a time-sensitive, customer-facing automation that must run in a timely fashion and meet a strict SLA (“Process A”). The others are various business processes that are not especially time sensitive.

In this case, I want to ensure that Process A can use any robot and runtime, and always has a robot available for its exclusive use, so I set it to use Any Robot, Any Machine.

For the rest of the processes, I want to ensure they have resources to run on 4 of the 5 available robots, but I don’t care which ones they run on, since they aren’t as time sensitive. For these, I would like to assign them to Robots 2-5, leaving Robot 1 for Process A.
However, with the current options, I cannot do this and have to assign one specific robot to one specific process, which is a waste of effort and extra planning.

I tried using Groups to accomplish the same thing, making one group that included all robots and one group that included Robots 2-5, but this does not work because Groups do not support unattended robots as they inherit properties from the group, and unattended robots must have their properties individually set. It would also help in this case to allow me to specify if group members should inherit properties from the group, or use their own defined properties.

1 Like
3

Hi @AaronTank

I think you should be able to achieve that with two different folders.

With two folders, you could assign the same machine template to each of them, and then apply custom account-machine mappings to both folders.

This way you should be able to map a single, specific robot account to your machine in one folder, but multiple robot accounts to your machine in the second folder.

This would allow you to simply leave the execution target as Any User/Any machine, because the underlying folder setup will take care of the proper division of the workload between the available mappings.

4

Thanks for the feedback; that is a good workaround I hadn’t condisdered and will look into implementing. I would prefer my solution outlined above because it would prevent another layer of folder maintenance for something that is 99% the same, but it will do in the meantime.

1 Like