The simplest case is when you configure single work queue (workbasket) inside a Work Group and point a VM to get the work from that work queue.
However it is quite often that one VM is not enough to process all tasks from the work queue, so you might want to use several VMs that receive the tasks from the same work queue.
Sometimes you would like to re-use the same VM to execute tasks from different work queues within the same work group. The tasks will be routed to VM based on the work queue priority, which is configured in the Robot Manager. Robotic code which you create in Pega Robotic Studio, should include robotic activity for each work queue to be supported.
Again you can share this mixed work between several VMs.
You can split your VMs into several workgroups and each workgroup can contain several work queues. But you can’t add the same VM to several workgroups. Which exact configuration to choose depends on your case and amount of work you want to assign to Robot(s).
To further amplify what Alex said above - it is really not a certain practice imposed by the product, but your use case that drives the appropriate set up of workgroups/work queues and configuration of VMs. You need to consider the following questions:
What is the volume of work that needs to be done and what are the SLAs? If you have a high volume homogeneous use case, then you will have the multiple VDI to single work queue set up.
If you have low volume multiple tasks, then are they done in mostly the same or different applications and do you need different IDs/security to do multiple tasks? If you can logically combine the multiple tasks in the same automation package, then you can use the same workgroup with multiple work queues for the ease of maintaining the RPA farm.
Who are the business owners and admins of your use cases? If you have multiple owners responsible for outcomes of the automations, then you should not be combining their activities in the same workgroup.
In summary the bot farm set up and configuration is a balance between achieving the operational goals and making it optimal for maintenance.
Thanks Grigory. I can understand the 1st two points but what would be the disadvantage of having all workqueues in a single workgroup? Even if we have multiple owners responsible for the outcomes, then in which scenario should the "Multiple VMs/MultipleWGs/ Multiple work queues" can be used?
Hi, Ric - remember that in an RPA configuration you have a 1:1 relationship between the Workgroup and an automation solution package deployed from the Robotics Studio that contains all possible automation activities that the bot can execute. The disadvantages could arise, if you end up bunching up too many unrelated automations for different applications in the same package. Another disadvantage of having a single workgroup for an organization is that you will need to coordinate change management across multiple stakeholders when you need to re-deploy the package even if you need to make a change to one activity. Further, if you have multiple stakeholders they would need to debate prioritization of their work queues in a single workgroup scenario. Thus, multiple VMs/Multiple WGs/Multiple work queues should be used when Robotics is adopted at enterprise level and you have multiple LOBs with different stakeholders building and maintaining their automations.
To move robots between work groups either manually or by using a schedule, you need to define a list of eligible work groups for each administrative operator that registered the robots. All the robots that were registered by the same administrative operator can move to those work groups.
This is a long dormant post. I would suggest posing your question in a post of its own unless it is related to this one. You might also need to pose a specific question, as it would be hard to elaborate on a 20 page document with anything not already contained in it.