Queue Priority and Robot Allocation at Month-End
Shared Services runs one Orchestrator tenant with 5 unattended robots across two machine templates, 120 queue items per hour, and three departments: Claims (priority 1, 8-hour SLA), Billing (priority 2, 24-hour SLA), and Audit (priority 3, 72-hour SLA). At month-end, Claims volume doubles for two days and Billing drops 40%. The queue currently uses FIFO and all robots pull from it. Claims complains that its items wait behind Audit items. There are 4 unattended runtime licenses and one robot is usually idle because its machine template has no matching license. The team wants to add a second queue.
1. Diagnose the licensing and allocation problem and propose a robot-to-work mapping for normal and month-end periods.
Read the worked answer
Five robots but four unattended runtime licenses means at most four concurrent unattended jobs; the fifth robot is not idle by accident, it is unlicensed. Confirm whether the machine templates consume runtime slots and whether one template is associated with a robot that has no license. Normal allocation: 2 runtimes to Claims, 1 to Billing, 1 to Audit; keep the fifth robot as a warm standby only if a license exists, otherwise remove it from the pool to avoid false capacity. Month-end: shift the Billing runtime to Claims for the two peak days, because Billing volume drops 40%. That gives Claims 3 runtimes when its volume doubles. Do not run five robots against four licenses and hope Orchestrator schedules around it; it will queue or fail.
2. Design queue priority and SLA so Claims is protected without starving Audit. Address whether a second queue is needed.
Read the worked answer
Use queue priority and deadlines rather than a single FIFO queue. Set Claims to High priority with an 8-hour deadline, Billing Normal with 24 hours, and Audit Low with 72 hours. Priority alone can starve Audit indefinitely, so add a reservation: for example, one runtime processes at least 10 Audit items per shift, or cap Claims items per robot per hour during normal periods. At month-end, temporarily raise Claims and lower Billing, but keep Audit's deadline visible.
A second queue is justified only if Claims needs separate ownership, reporting, or SLA enforcement; otherwise two queues split reporting and make robot allocation harder. If you add a second queue, define a single reference ID and prevent the same item from existing in both. Monitor queue SLA breach rate and average wait by priority.
3. What Orchestrator metrics would you monitor, and what would you avoid doing?
Read the worked answer
Monitor items processed per hour, average processing time, queue item status counts, SLA or deadline breaches by department, robot utilization, license consumption, and retry or failure rate. Track wait time separately from processing time: Claims' complaint is about wait, not throughput. Review month-end trends across two cycles before resizing licenses.
Avoid a permanent 'Highest' priority for Claims, because it converts a peak problem into chronic starvation for Audit. Avoid adding robots without licenses, and avoid measuring success only by total items processed: a queue can look busy while breaching every SLA. Also avoid changing priority and adding a second queue in the same release, since you will not know which change fixed or broke the service.