Blue Prism Control Room Digital Workers Explained for Beginners

Quick Answer: This guide explains Blue Prism control room digital workers the way an operator actually meets them. A digital worker is a named, licensed runtime resource; a session is one running instance of a process on that resource; the Control Room is the console where both are scheduled, monitored and governed, alongside the work queues that feed them and the logs that explain what happened when something broke.

Digital Workers, Sessions and Environments: The Mental Model

Start with the vocabulary, because Blue Prism is unforgiving if you carry UiPath or Automation Anywhere words across. A digital worker is a runtime resource — a named entity like DW-INV-04 that exists on a host machine and holds a licence. It is not a process. It is closer to a licensed employee seat. A session is one running instance of a process (or business object) on that digital worker at a particular time. The same digital worker can run many sessions over a day; at any moment it runs one.

Around that sit three more ideas. An environment is a complete, separate Blue Prism installation — Development, Test, Production — with its own Control Room data, which is what makes change control possible rather than optional. A business object (VBO) holds the application-modelling work done in Object Studio, so the same SAP or web interactions are reused by every process. And a work queue holds the backlog of items to be processed, which is what allows a process to be resilient: work arrives in the queue, sessions drain it, and the two are decoupled.

If you take one sentence away: processes are what runs, digital workers are what runs it, queues are what feeds it, and the Control Room is where a human can see all three. A Process Controller is the person who lives in this console during a shift, and it is the entry rung of the Blue Prism developer career ladder in India.

Blue Prism Control Room Digital Workers: What Each Area Holds

The classic Control Room is a Windows client organised into areas. Since version 7 the same functions are available as a browser-based console, and SS&C’s newer WorkHQ generation reorganises them into Digital Workers, Operations and Control Center areas — but the underlying objects are the same, so learning the classic layout still transfers.

Two habits separate people who are good at this from people who are not. They read the queue before they read the session — a queue with a growing pending count tells you more than a red session. And they read the log attached to the work item, not just the session log, because the item remembers which session last touched it and the jump straight from item to log is one right-click.

How Work Reaches a Digital Worker: The Queue Model

Everything important about Blue Prism operations happens in the work queues. Items are added to a queue by a process calling the Add to Queue action on the internal Work Queues business object. A consuming process repeatedly calls Get Next Item, which locks one item to that session — no other session can touch it — and then works it. When finished, the session releases the lock by completing the item, deferring it to a later time, or marking it with an exception.

Queue item lifecycle (Internal - Work Queues business object)

ADD TO QUEUE      item created           Status = Pending
      |
GET NEXT ITEM     item locked to session Status = Locked  (one session only)
      |
      +--> work succeeds --> MARK ITEM COMPLETE      Status = Complete
      |
      +--> data cannot be worked  --> MARK ITEM AS EXCEPTION
      |                               Status = Exception, message recorded
      |                               (consumes one of the queue's maximum attempts)
      |
      +--> transient problem      --> SCHEDULE ITEM (defer)
                                    back to Pending at a future date/time

Queue configuration that decides the behaviour:
  Maximum attempts      how many retries an exception may consume (default: none)
  Key field             deduplicates items by a chosen data field
  Tags                  filter Get Next Item calls by category or source
  Retry on unexpected session termination   requeues items left locked by a crash
  Encryption            encrypts queue contents at rest

Item statuses are worth memorising for interviews, for the Blue Prism certification roadmap exams (which test these action names directly) and for 3 AM debugging: Pending, Locked, Complete, Exception, Deferred. And two operational facts bite teams regularly. First, marking items with an exception from the Control Room never creates a retry, regardless of how many retries the queue allows — retries are generated by the process, so if an operator exception-marked a batch, those items are finished until someone forces a retry. Second, completed and exceptioned items are not a permanent archive: in the newer WorkHQ queues they are retained for 90 days, and in Blue Prism Enterprise their longevity depends on your database retention policy, which is why anyone who needs an audit history exports it.

Scale comes from active queues. Rather than hand-starting twelve sessions and hoping they stay busy, you set a target number of resources to work a queue, and Blue Prism starts and stops sessions to hold that target. It only pays off at real volume — dozens of sessions against one queue — but at that volume it eliminates the most common operational failure in RPA: idle robots beside a growing backlog.

Exception Handling: Where Most Blue Prism Processes Go Wrong

Blue Prism distinguishes three exception types, and the classification decides what happens next. UiPath expresses the same split as BusinessRuleException versus application exceptions inside UiPath REFramework, so the thinking transfers even when the syntax does not. Internal exceptions come from Blue Prism’s own stages. System exceptions come from the environment or target application — a timeout, a crashed client, a missing field. Business exceptions mean the data cannot be worked: a customer ID that does not exist, an amount outside a permitted range. Retrying a business exception is pure waste; retrying a system exception sometimes saves the item.

When an exception is raised by an Exception stage it bubbles up the process hierarchy until a Recovery stage catches it, after which a Resume stage decides where processing continues. If nothing catches it, the session terminates — which is exactly how you end up with locked queue items and the incident described below. The design standard most teams follow is a top-level main process that opens and closes the application and wraps sub-processes for each business step, so an exception in step three does not force a full application re-login before step four can retry.

For queue-driven work, the pattern that keeps queues clean is: business exception means mark the item with an exception carrying a message a human can act on; system exception means raise, recover, and let the queue’s maximum attempts produce a retry; and anything that needs to come back hours later gets deferred rather than exceptioned.

What Actually Happens at Work: 12 Digital Workers and 18,000 Stuck Items

At 03:10 a monitoring alert fired on queue depth for a claims intake process in a Mumbai insurer. By 03:25 the on-call controller could see the real picture: eighteen thousand pending items, twelve digital workers listed as available, and not a single item moving. The process had been draining about 4,000 items an hour; it was now doing nothing.

The item-level log told the story in two minutes. A Windows update had restarted one of the host machines at 02:50. Three sessions terminated mid-item, and because the queue had neither the retry-on-unexpected-termination option enabled nor any maximum attempts configured, those three items stayed locked forever. Worse, the process’s own retry logic was a manual re-run with a check that skipped locked items — so the consuming sessions found nothing to work and quietly idled while the backlog grew.

The repair was unglamorous and instructive. The controller right-clicked the locked items, marked them with an exception carrying a clear message, then used force retry to return them to Pending once the hosts were stable. The configuration change was three settings: enable retry in the event of unexpected session termination, set maximum attempts to two, and set a key field on the source reference so duplicates could never enter the queue — a change that later caught an actual duplicate claim payment worth more than the quarter’s platform support contract. Finally, patching windows moved onto the resource calendar so they no longer overlapped the 01:00–05:00 process window.

What the team took away was a rule, not a fix: a Blue Prism process is only as resilient as its queue configuration. Retries, keys, tags and calendars are not admin chores; they are the automation’s immune system.

Training Resources

Control Room operations, queue design and exception handling are the parts of Blue Prism you cannot fake in an interview. Build them for real with SkilBrill Blue Prism Training — Process and Object Studio, work queues, recovery design, Control Room operations and ROM-based scaling, with labs modelled on live estates.

FAQ

What is the Blue Prism Control Room used for?

It is the operations console for a Blue Prism estate: scheduling processes, monitoring digital workers and sessions, managing work queues, and reading the logs and dashboards that explain what the digital workforce did and why.

What is a digital worker in Blue Prism?

A named, licensed runtime resource that executes automations. It is not the automation itself — the process is the automation, and a digital worker is the seat it runs on. Sessions are the individual running instances.

How do retries work in Blue Prism work queues?

Each queue has a maximum attempts setting; an item that is marked with an exception by a process consumes one attempt and is requeued until the limit is hit, after which it stays in Exception status. You can also enable retry when a session terminates unexpectedly, and force a retry from the Control Room. Exception-marking items from the Control Room never creates retries.

Where do I see why a digital worker failed?

Two places. The session log under the System and logging area shows the full run with the failing stage and error text. For queue-driven processes, right-click the work item and choose View Log to jump to the log of the session that last worked that item — usually the fastest route to the answer.

What is the difference between an active queue and a normal queue in Blue Prism?

A normal queue is worked by sessions you start and manage yourself. An active queue takes a target number of working resources and Blue Prism starts and stops sessions to hold that target, which removes the idle-robot problem at high volumes — it is only worth using when a queue needs dozens of concurrent sessions.

Written by SkilBrill Training Institute

October 15, 2026 · 10 min read