Work queues

What it does

A Dataverse-backed queue of work items that automations, cloud flows and people all draw from. Items carry a name, a priority, an input payload, an expiry and a status, and the queue hands out the next one on request. It decouples "load the work" from "do the work", which is what lets you run the same process across many bots at once.

Key facts

Work queues are a premium RPA feature — a premium Power Automate licence and the Environment Maker role (or another role with access to the work queue tables) are the entry requirements.
Item statuses are Queued, Processing, On hold, Processed, Generic exception, IT exception, Business exception and Processing timeout. Transitions are constrained: only Queued items can be dequeued, and Processing can only move to Processed or an exception.
Priority is Low, Normal or High. Higher-priority items get processed first when mixed in the same queue.
The desktop flow action Process work queue items pulls the oldest Queued item, flips it to Processing, and loops. Update work queue item, Add work queue item(s) and Requeue item with delay cover the rest of the lifecycle.
Auto-retry on IT exception can be set as a queue-level default and overridden per flow. While the retry count is below the maximum, the item stays on the machine instead of being requeued, and a CurrentRetryCount variable is available for custom logic.
A work queue SLA strategy sets a time-to-live, an "SLA violated after" threshold and an at-risk percentage. Items added without an explicit expiry inherit the violation threshold as their expiry, and Dataverse triggers can fire on at-risk and violated items.
Optional JSON or XSD schema validation on the input field. Once a schema is attached to a queue it can't be changed. JSON schema draft 3 is what's currently supported.
Items can be loaded from a desktop flow, a cloud flow, bulk CSV import, or the Dataverse Web API. Export of work queue items to CSV reached general availability in July 2026 (2026 wave 1).

When to use / skip

The moment you're about to write a desktop flow that reads a spreadsheet and loops through the rows, stop and use a work queue instead. The spreadsheet loop gives you no concurrency, no retry, no visibility of where it got to, and no way for a human to intervene on one bad row. Work queues give you all four. Skip them for genuinely single-item, event-driven automations where there's no batch and no backlog — the overhead isn't worth it for a flow that processes one approval at a time.

Configuration decisions

Whether item input is free-form or schema-validated, which is really a decision about who owns data quality upstream.
SLA thresholds and at-risk percentage, plus what actually happens when an item goes at-risk — an email is the minimum, a fallback route is better.
Auto-retry count for IT exceptions, and which failures count as IT rather than business.
Which exception statuses map to which remediation path, and who owns the On hold pile.
Expiry per item versus the queue default, which matters when work has a hard cut-off like a token lifetime.

Gotchas

Items get stuck in Processing when a desktop flow dies mid-run. Nothing releases them automatically — you need a cloud flow to sweep and requeue.
Deleting a work queue permanently deletes every item and all processing history with it. There's no soft delete.
Item names and values can't be edited while an item is Processing, which surprises people trying to fix a bad payload in flight.
The schema is immutable once set, so a rushed first draft of the JSON schema becomes a permanent constraint.
If you select a queue dynamically by variable, you must pass the work queue ID, not the display name.

Consultant notes

Work queues are the clearest way to show a client that RPA is an operational capability rather than a script. The monitoring pages sell the design on their own.
Use the exception statuses properly from day one. A queue where everything fails as "generic exception" tells operations nothing and undermines the whole point.
Design the human-in-the-loop path explicitly: who reviews On hold items, in what tool, and how items get released. Clients rarely ask for this and always need it.
Pair work queues with a machine group or hosted machine group. A queue in front of a single bot just makes the backlog visible rather than shorter.

Worth another look once the client's exception volumes are real — the retry and SLA settings almost always need retuning after go-live