Work queue

What is a work queue?

A work queue is a managed list of individual work items that an automation picks up and processes. Each item stands for one business task: a single invoice, a claim, a customer change, or an order.

The queue separates supply from execution. Producers keep adding items while one or more bot runners claim them at their own pace. That decoupling is what lets you add machines and process the backlog faster without rewriting the process.

Status, priority, an attempt counter, and exception details make it visible what is waiting, what is being worked on, what succeeded, and what needs a person. In RPA and Power Automate desktop flows, work queues are the usual way to scale a process past a single machine.

Work items and payload

An item carries a unique key and the minimum data needed to find or perform the work. Large documents and sensitive fields are usually linked through a secure reference rather than copied into the item itself.

Use a business key to spot duplicates, for example vendor plus invoice number. The queue's own record identifier does not stop the same task being added twice, so the check has to come from data you control. Record the source, the creation time, a deadline, and a priority where it matters, and avoid free-form payloads with no schema or version.

The lifecycle of a work item

A new item sits in a queued state. A runner claims or leases it, and the item moves to processing. A lease stops two runners working the same item at once, and it has to be able to expire after a safe interval so a crashed runner does not lock the item forever.

On success the item is completed with a result reference. A transient technical fault can trigger a controlled retry. A business problem, such as a missing purchase order, moves the item to a separate exception status for review. Power Automate work queues make this explicit with statuses including queued, processing, processed, on hold, and separate generic, IT, and business exception states.

System errors versus business exceptions

A timeout, a temporarily unreachable application, or a locked session is usually technical. Retrying can help once the system recovers. Power Automate reflects this with an auto-retry option for IT exceptions, where the machine holds the item and retries it up to a set count without requeuing.

An unknown vendor, a missing approval, or a request that is rejected on its merits does not change by running the same step again. That is a business exception, and it belongs in a review bucket, not a retry loop. Classify faults on purpose. An endless retry on invalid data burns capacity and hides work that actually needs a decision.

Worked example: an invoice queue

Every incoming invoice becomes one item after a duplicate check. The payload points to the document and the vendor and carries a payment deadline.

Runners take the most urgent items first. A transient ERP error gets up to three attempts with a growing wait between them. A missing purchase order is sent to a separate exception status where a buyer can act on it. After posting, the item keeps the ERP reference, and any retry checks that reference and the business key before it tries to post a second time.

Work queue versus message queue

A message queue moves messages between systems and offers delivery guarantees such as at-least-once. A work queue usually adds business status, manual review, priority, and operational search on top, so people and bots can both see and steer the work.

A message can create a work item, and both can sit on the same broker, but their contract and their purpose differ. With at-least-once delivery you should assume a message or item can appear again, so design the consumers to be idempotent.

Priority, fairness, and monitoring

Priority helps you drive deadlines and risk, but without limits a steady stream of rush work can starve ordinary items. Combine priority with item age, service level, and available capacity, and record who is allowed to raise a priority and why.

Track intake, backlog, item age, processing time, success rate, retries, and the reasons behind exceptions. Measure waiting time per class rather than on average, because a small group of old items can hide behind a healthy average. Alarm on a backlog that only grows and on items that show no progress, and set retention for completed items. A work queue is an operational system, not an unlimited archive.