Control Room and Work Queue Management
Runtime operations
Control Room is the operational console: it manages Processes, Resources (the machines and logins that run them), Sessions (a running instance of a process on a resource), and Queues. A Digital Worker runs one session at a time on a resource; scheduling and triggering determine when sessions start.
Work Queues decouple data from processing. Items carry a key, data, status, priority, tags, and exception reason. Statuses to know: New, In Progress, Completed, Exceptioned, Deferred, and Locked (held by a session). A session gets the next item with Get Next Item, filtered by tags, priority, and status; the item is locked to that session so two workers do not process it. On success the item is marked Completed; on failure it is marked Exceptioned with a reason. Deferred items return later, which suits transient conditions such as an application being unavailable.
Traps in questions
- Assuming an item is released automatically on failure - the process must explicitly mark or defer it, or it stays locked until the session ends.
- Confusing priority with ordering of tags; both filter selection but priority ranks.
- Believing Control Room edits process logic; it controls runtime, not design.
- Forgetting that exceptioned items can be retried after correction, whereas completed items are done.
- Overlooking that a resource can only run one session at a time.
Rule of thumb
Treat every queue item as a unit of work with a lifecycle: get, lock, attempt, then complete, defer, or exception with a meaningful reason. Reasons are your audit trail.
Worked example
Two workers pull from one queue. Worker A gets item 101 and locks it; Worker B's Get Next Item skips 101 and takes 102. If A fails, the process must mark 101 Exceptioned or Deferred - otherwise it remains locked and invisible until the session ends.