Hi @MinhDinh ,
Work queues and machine groups are different in many ways but the primary way to differentiate them is work queues are your dataverse tables to queue your transactions for processing. Machine groups are the virtual hardware that do the work.
So one example to describe more in detail - say you have two VMs and you have put them in a machine group and you point your cloud flows to run the RPA actions in your machine group connection. So when one of your cloud flows launch an RPA action, it will assign one of the machines in your machine group and process your desktop flow.
If you have two machines in your group, technically you can run two desktop flows concurrently, one on each machine (by default). So an example would be you have your cloud flow processing email content to RPA and it fires for each email and in the example, you get two emails 30 seconds apart; in this case you will have two concurrent flows running in your machine group.
Your work queue again is where you can store your "transactions". Think of work queues to something similar to a table in an excel workbook with some data you want to process in RPA. Instead of using "list rows present in a table", you are using process work queue items, converting from json to a custom object, and then processing your transactions from the work queue (instead of a excel table as an example).
I prefer work queues they will keep track of your transaction statuses, such as queued, processing, on hold, generic exceptions, IT exceptions, business process exceptions, etc and one of the many benefits is your RPA can restart (or even run on-demand or on a short scheduled cloud flow) and process all "queued" transactions in your work queue. So in this sense, it is very easy to know where to start again and keep going.
I am using machine groups and work queues and I can almost guarantee you that after you use work queues once, you will convert every single RPA flow you have to use work queues; BTW, machine groups are awesome too and they go hand-in-hand.
