You built a bot. It works. Then someone hands you 4,000 records instead of 40, and the thing that ran clean in testing is still grinding at 6 a.m. with half the file untouched. That is the wall every operator hits, and Automation Anywhere workload management is the feature built to break it. Automation Anywhere workload management is a Control Room capability that splits one large volume of work into individual work items, holds them in a queue, and distributes them across multiple devices so they process in parallel instead of one at a time.
Today is a process post, so we are going to walk the actual sequence. Not the sales pitch. The order of operations, the terms the Control Room uses, and the step most people skip.
Key takeaways
- Automation Anywhere workload management (WLM) breaks a large automation volume into smaller work items, queues them, and runs them across a device pool in parallel.
- Creating a standard queue in Automation 360 requires the AAE_Queue Admin role, which carries the permissions to view and manage queues, create queues, administer all queues, and view in progress activity.
- Queue setup has five parts: a queue name, the queue owners, participants, and consumers, the work item structure, and auto retry settings for failed work items.
- A queue, Bot Runner, and device pool are attached to an automation from the Run bot with queue page, and a queue already in use cannot be selected again.
- Automation Anywhere reports customers averaging 250 percent ROI within 6 to 9 months on WLM, with top performers at 380 percent. Those are vendor reported figures, not audited results, so measure your own throughput before you quote anyone else’s.
- Automation Anywhere Community Edition is free and runs on up to five machines for qualifying small businesses, but its product page does not state whether workload management is included.
Why one bot on one machine stalls
A standard task bot is a single worker. It opens record one, does the work, closes it, opens record two. Run time scales in a straight line. Forty records at nine seconds each is six minutes. Four thousand records at nine seconds each is ten hours, and that assumes nothing times out.
There is a second problem that hurts worse. When a loop like that fails on record 2,100, you do not get a clean restart. You get a bot that has to be told where it left off, and a developer manually editing a source file at midnight. If you have only ever built a first A360 bot against a small test file, this is the failure mode waiting on the other side of go live.
Queues fix both. Each record becomes its own unit with its own status. Parallel devices pull from the same queue. A failure is one work item, not the whole run.
The SPLIT Method for Automation Anywhere workload management
This is the sequence I use. Five steps, in order, because doing them out of order is what forces a rebuild.
S: Size the batch
Before you touch the Control Room, get two numbers: real peak volume and seconds per record. Not the estimate the client gave you. Run the existing bot against a sample and time it. That gives you an automation baseline you can prove improvement against later.
If peak volume times seconds per record fits inside your processing window with room to spare, stop here. You do not need queues. Complexity you do not need is its own kind of outage.
P: Pick the work item structure
A work item is one unit of work in the queue, and its structure is the set of columns that unit carries. Think of it as the schema for a single record: invoice number, vendor, amount, due date, whatever the bot actually reads.
Define this before you build the bot, because the bot references those field names. Changing the structure after the automation is wired up means touching every action that reads a field. Define once, build against it.
L: Load the queue
Now create the queue in the Control Room. Automation Anywhere’s documentation is specific about what that takes: a Control Room administrator has to assign you the AAE_Queue Admin role first, with permissions to view and manage your queues, create queues, administer all queues, and view your in progress activity. No role, no queue. That is usually the ticket that delays a project by a week, so open it early.
Creating a standard queue means naming it, assigning queue owners, participants, and consumers, defining the work item structure from the step above, and configuring auto retry for failed work items. You can also save it as a draft and finish the rest later.
Work items get loaded from sources like a CSV file, an API, or another automated task. The Workload package inside the bot includes an Insert work item action, which moves a work item from one queue into another during a run. That is how a triage queue feeds a processing queue.
One habit to carry over: queue data is still production data. If the work item carries anything sensitive, the login the bot uses to touch it belongs in the Credential Vault, not in a variable.
I: Isolate the failures
Auto retry is a setting on the queue, and it covers the transient stuff: a slow page, a dropped session, a lock that clears in thirty seconds. It does not cover bad data. A work item with a malformed date will fail the retry too, three times, and then sit there.
So you still write a real error path inside the bot. Catch the exception, write the reason onto the work item, and move on to the next one instead of killing the run. The rules in Automation Anywhere error handling apply unchanged here. Queues change how work is distributed. They do not excuse you from handling the exception.
A queue that silently parks 300 failed work items is worse than a bot that crashes loudly on record one.
T: Track the throughput
Attach the queue, the Bot Runner, and the device pool to the automation from the Run bot with queue page. A device pool is just a group of devices. A Bot Runner is a device that runs the automation. You choose the number of Run as users, and the automation waits in the queue until that user and the devices are free. Queues already in use show as disabled, and you cannot stack multiple queues to add more Bot Runners.
Then watch the numbers that matter: work items completed per hour, failure rate by reason, and total time to clear the queue. Hours saved is a soft metric. Items per hour is a number the client can check.
Example scenario: 4,000 invoices on a Friday night
Example scenario, not a client result. An accounts payable team drops 4,000 invoices into a folder every Friday at 5 p.m. and needs them keyed by Monday at 8 a.m. One bot at nine seconds per invoice needs roughly ten hours of clean run time to finish.
- Size: 4,000 items, 9 seconds each, 63 hour window. It fits, barely, with zero margin for a single failure.
- Pick: the work item carries invoice number, vendor ID, amount, due date, and file path. Five fields, nothing decorative.
- Load: a loader bot reads the folder and inserts 4,000 work items into the queue at 5:05 p.m.
- Isolate: auto retry handles portal timeouts. Anything with a missing vendor ID gets marked with a reason and left for a human on Monday.
- Track: four devices pull from the queue in parallel, so the throughput target becomes items per hour rather than one long serial run.
Same bot logic. Different distribution model. The reason this matters for a one person operation is that it is the difference between selling a demo and selling a system that holds up on the worst Friday of the quarter.
Action steps for your first queue
- Time your existing bot against 50 real records and write down seconds per record.
- Multiply by peak volume. If it fits your window with margin, skip queues entirely.
- Request the AAE_Queue Admin role from your Control Room administrator today, not the week you plan to build.
- Write the work item structure on paper first. Lock the field names.
- Build the loader bot and the processor bot separately. One fills the queue, one works it.
- Set auto retry, then add your own error path for data problems retry cannot fix.
- Run 200 items against two devices before you run 4,000 against four.
Frequently asked questions
What is workload management in Automation Anywhere?
It is a Control Room capability that breaks a large automation volume into individual work items, holds them in a queue, and distributes them across devices for parallel processing. Automation Anywhere’s documentation describes it as a queue based model aimed at high volume work and at processes with a service level agreement to meet.
What role do I need to create a queue in Automation 360?
The AAE_Queue Admin role, assigned by a Control Room administrator. Automation Anywhere lists the required permissions as view and manage my queues, create queues, administer all queues, and view my in progress activity.
Do I need workload management for a small bot?
Usually no. If peak volume times run time per record fits inside your processing window with margin, a single task bot is simpler to build, test, and hand off. Queues earn their complexity when volume is high, spiky, or deadline bound.
Is workload management available in Automation Anywhere Community Edition?
The Community Edition product page does not say. It confirms the edition is free, built on the Automation 360 cloud platform, and limited to no more than five machines for qualifying small businesses, but it does not list workload management as included or excluded. Confirm with Automation Anywhere before you plan a client build around it.
How is this different from just adding more bots?
Adding bots without a queue means splitting the source file by hand and hoping two bots never grab the same record. A queue is the shared source of truth for which item is claimed, done, or failed. That is the whole point.
Recap
To recap: a single bot processes work in a line, and that line breaks at volume. Automation Anywhere workload management turns one long run into queued work items distributed across devices. Size the batch, pick the work item structure, load the queue, isolate the failures, track the throughput. Get the AAE_Queue Admin role before you need it, and do not reach for queues when a simple bot already fits the window.
This is the same principle behind every AI system for online business worth building. You are not working faster. You are changing how the work is distributed so the ceiling stops being you.
Sixteen years of enterprise automation taught me that the queue is not an advanced topic. It is the line between a demo and infrastructure. Subscribe to the blog and I will keep walking the process posts one step at a time.
References
Automation Anywhere. (n.d.). Add queue, Bot Runner, and device pool. Automation Anywhere Documentation. Retrieved October 14, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/workload/cloud-add-queues-device-pools.html
Automation Anywhere. (n.d.). Community Edition. Automation Anywhere. Retrieved October 14, 2026, from https://www.automationanywhere.com/products/enterprise/community-edition
Automation Anywhere. (n.d.). Create standard queues. Automation Anywhere Documentation. Retrieved October 14, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/workload/cloud-create-queue.html
Automation Anywhere. (n.d.). WLM: Getting started. Automation Anywhere Documentation. Retrieved October 14, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/wlm-getting-started.html
Automation Anywhere. (n.d.). Workload Management in Automation 360. Automation Anywhere Documentation. Retrieved October 14, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/control-room/workload/cloud-workload-an-overview.html
Automation Anywhere. (n.d.). Workload package. Automation Anywhere Documentation. Retrieved October 14, 2026, from https://docs.automationanywhere.com/bundle/enterprise-v2019/page/enterprise-cloud/topics/aae-client/bot-creator/commands/cloud-workload-command.html
Leave a Reply