Dynamic Process Orchestration
Replacing Blue Prism's native scheduling model with a priority-driven orchestration architecture — a 24/7 parent process, dynamic resource utilisation, and programmatic email handling via Microsoft Graph API.
Blue Prism's native scheduling model is designed for simplicity. Processes are structured as a sequence — load queue, process queue, report queue — each step running after the last, with runtime resources allocated upfront per schedule. For a small estate with predictable, uniform workloads, that model works.
As the estate grows and workloads become more varied — items arriving at different times, at different priorities, competing for a shared pool of runtime resource — the limitations of the native model become structural constraints. High-priority work waits behind lower-priority items already in execution. Resources sit idle between scheduled runs. And the web of schedules required to manage a complex estate becomes progressively harder to maintain and reason about.
The scheduling model required manual configuration for each process set, resources allocated upfront per schedule, and sequential execution that couldn't respond to what was actually in the queue. High-priority work items waited. Resources sat idle. Reporting was a manual dependency bolted onto the end of each sequence. The result was a complicated web of interdependent schedules that grew harder to manage with every addition to the estate.
The question was whether it was possible to replace the entire model with something that responded to workload dynamically — so the most important work was always being processed, by whatever resource was available, without manual intervention.
The solution replaced Blue Prism's native scheduling model entirely — not by extending it, but by building a different architecture on top of the platform's work queue infrastructure.
Parent orchestrator and resource pool
A pool of runtime resources was configured to run a single parent Blue Prism process continuously — 24 hours a day, 7 days a week. The parent process iterated in a tight loop, querying the Blue Prism work queue info table directly to identify the highest-priority item currently available, then processing it. As soon as a resource finished one item, it immediately picked up the next. Resources were never idle while work remained in the queue. Scheduling was reduced to its simplest form: load queues running at defined times, and the parent process running continuously.
Priority-based queue management
The parent process classified each work item's priority at the point of selection — not at the point of loading. This meant prioritisation was dynamic rather than predetermined: if a high-priority item arrived while lower-priority items were already in the queue, the next available resource would pick it up ahead of them. Work queue management went from a static allocation problem — decide upfront how many resources each schedule gets — to a continuous optimisation: always process the most important available item, with whatever resource is free. Reporting triggered automatically when the queue cleared, eliminating the manual dependency at the end of each run.
Email orchestration via Microsoft Graph API
The same orchestration model was applied to outbound email. Any process that needed to send an email loaded an item into a dedicated email work queue rather than sending directly. A separate email parent process ran continuously against that queue, picking up the most recent item by priority and dispatching it via Microsoft Graph API. Centralising all email sending through a single queue meant priority was consistent across the estate, volume was manageable, and the sending mechanism was a single point to maintain and monitor. The architecture was the same pattern as the work queue orchestrator — always running, always processing the highest-priority item available.
The architecture required deep familiarity with how Blue Prism manages work queues internally — specifically, the structure of the work queue info table and how it could be queried to surface priority in real time. Building directly against the database, rather than through the platform's native scheduling layer, was what made the dynamic prioritisation possible.
The result was a scheduling model that was both simpler and more capable than what it replaced. Simpler because the web of interdependent sequential schedules collapsed into a single continuous parent process. More capable because it responded to workload dynamically rather than executing a predetermined sequence regardless of what was actually in the queue.
The Graph API email integration extended the same principle to outbound email — replacing direct sends scattered across the estate with a centralised email work queue and a single continuous parent process. Once the orchestration pattern was established, it became the natural template for any workload that needed to respond to demand rather than a clock.
The scheduling model went from a complicated web of sequential processes to a single, elegant architecture that responded to workload in real time.
Resources were fully utilised whenever work was available. High-priority items were processed immediately rather than waiting for their scheduled window. Reporting was automatic. And the estate became significantly easier to manage — adding a new process meant adding it to the queue, not restructuring a schedule.
Continuous Improvement in ROM2 asks whether the CoE has the mechanisms to identify structural limitations in how it operates and act on them — not just to fix problems reactively, but to redesign the way the programme works when the existing model has reached its ceiling. This orchestration architecture is that in practice: a platform constraint identified, understood at a deep level, and replaced with something fundamentally better.
Assess your CoE's continuous improvement maturity →