An orchestrator queue is the managed, persistent work item buffer maintained by the RPA orchestrator through which work is distributed to unattended bots for processing. Work items — individual transactions, documents, or tasks — are pushed to the queue by a feeder process (a bot, an API call, an upstream system, or a human via a queue portal), and processing bots pull items from the queue, process them, and update their status. The queue is the primary mechanism for achieving reliable, scalable, load-balanced unattended automation: rather than bots operating on scheduled batches of unknown completeness, they operate on a queue of discrete, tracked items with defined status at every point in the processing lifecycle.
How It Works
Each queue item moves through a defined status lifecycle: New (added to the queue, awaiting processing), In Progress (locked to a specific bot for processing), Successful (processed without error), Failed (processed with an error that exhausted retry attempts), and Retried (returned to the queue for another attempt after a transient failure). The orchestrator manages the locking of in-progress items — ensuring that only one bot processes a specific item at a time, preventing duplicate processing in multi-bot environments. The queue provides visibility into processing throughput, exception rates, and the age of unprocessed items — operational metrics that the automation monitoring function uses to assess whether the bot fleet is keeping pace with queue inflow.
Queue item payloads carry the data needed by the processing bot — structured as key-value pairs in JSON format. The payload design determines what data must be present when the item is added to the queue versus what data the processing bot retrieves from source systems at processing time. Items with complete payloads (all required data included at queue entry) process faster and are more resilient to source system unavailability at processing time; items that require the bot to query source systems for payload data at processing time are faster to enqueue but more vulnerable to source system unavailability.
Design Considerations
Queue capacity planning is a critical design consideration for high-volume finance automation. Queue depth at peak — the number of items simultaneously in the queue awaiting processing — determines the required bot fleet size and the achievable processing SLA. For month-end close automation where large batches arrive simultaneously, the queue design must accommodate burst inflow without the backlog growing beyond the processing window. Capacity modelling should be based on peak observed inflow rates, not average rates.
What Breaks in Production
The specific failure that produces corrupted queue state in production is a bot that crashes mid-transaction without releasing its In Progress lock on the queue item. When a bot fails catastrophically — an unhandled exception at the process level, a machine reboot, an orchestrator connection loss — the item it was processing may remain in In Progress status indefinitely, because the status update to Failed is never sent. The item is invisible to other bots (locked) and to monitoring dashboards (not in the exception queue). After the orchestrator’s transaction timeout period — configurable per queue — the item is automatically marked as abandoned and can be retried. Configuring the transaction timeout at a value slightly longer than the maximum expected processing time for a single item prevents legitimate long-running transactions from being incorrectly marked as abandoned while ensuring genuinely stuck items are recovered automatically.
How Loop Wise Solutions Designs for This
In orchestrator queue design, we specify the transaction timeout, the maximum retry count, the retry interval, and the failure escalation path for each queue as explicit architecture decisions. We design the payload structure to include the minimum data required for processing — avoiding large payloads that increase queue storage costs — and document the payload schema as a contract between the feeder process and the processing bot that both must honour. Queue configuration changes in production are subject to change control, because a change to retry count or timeout directly affects the processing behaviour of every item currently in the queue.
