As there are not much changes we need to make to the RE Framework, we build almost every `bot’s this way. Normally wherever you will have transactional process and can be processed independently, you can use multi bot architecture.
The idea is you can assign multiple bot’s to process single queue items to speed up the work.
@Steven_ds_55
Multi-bot architecture means using multiple bots to work together on a process. Instead of one bot doing all the work, multiple bots share the workload, making automation faster and more efficient.
Also, If one bot fails, others can continue the work.
hope it helps!!
Thin Client Robots in UiPath, which typically means multiple robots working on different aspects of a process rather than performing the exact same task.
Key Points:
Work Sharing but Not the Same Task:
One bot might handle backend processing (e.g., fetching data from a database, performing calculations, or sending emails).
Another bot might handle frontend processing (e.g., interacting with a web application, filling out forms, or navigating UI elements).
Separate Licensing:
The Unattended Robot license is used for backend automation (runs in the background without human intervention).
The Attended Robot license is used for frontend automation (requires some level of human interaction).
In a Hybrid Automation Setup, both types of bots collaborate but have different roles.
Use Case Example:
Suppose you need to process invoices:
Backend Bot: Reads invoices from emails, extracts data using OCR, and updates a database.
Frontend Bot: Logs into an ERP system and enters the extracted invoice data manually.
Difference from Parallel Execution:
The bots do not work on the same task at the same time. Instead, they divide responsibilities to improve efficiency.
This setup is different from multi-bot execution, where multiple robots work on the same queue items simultaneously.
Please find following explanation on how to implement such a setup in UiPath?
Implementing Thin Client Robots in UiPath
To implement a Thin Client Robot setup where one bot handles backend processing and another bot handles frontend automation, follow these steps:
Identify the Process and Task Segmentation
Analyze the workflow and split the tasks into:
Backend Tasks (Unattended Robot)
Database operations (SQL, Excel, API calls)
Email processing (reading and extracting attachments)
Data extraction (OCR, document parsing)
Frontend Tasks (Attended Robot)
Logging into web/desktop applications
Filling out forms
Navigating UI elements
Develop the Backend Bot (Unattended Robot)
This bot will handle data processing without interacting with the UI.
Assign the backend bot to a machine where it can run unattended.
Assign the frontend bot to a user’s machine for attended execution.
Use Queues to pass data between the bots.
Example:
Backend Bot:
Reads emails, extracts invoice details, and adds them to a queue.
Frontend Bot:
Picks up the invoice details from the queue and enters them into the ERP system.
Monitor and Optimize
Use Logs and UiPath Insights to track performance.
If the backend process has high volume, scale with multiple unattended robots.
Optimize frontend automation using hotkeys, selectors, and retry mechanisms.
Benefits of This Approach
Parallel Processing – Faster execution by handling tasks in separate bots. Better Resource Utilization – Unattended bots handle data-heavy tasks, while attended bots focus on UI tasks. Scalability – Easily add more robots as needed. Resilience – If one bot fails, the other can retry or escalate the issue.
The main change in my opinion is making sure the Framework can utilize the Output property of a queue item. Annoying the default activities from UiPath to update a queue item don’t support this in a flexible manner so it requires some hard coding of dictionary keys and outputs.