Blue Prism Attended Automation – Polling, Scheduling & Roles

Digital Workers in an off-desktop attended configuration be fully utilized 24x7, shifting between both attended and unattended processes. Digital Workers can also swarm work queues to expedite processing time and operate in parallel to humans, allowing people to do other tasks as the same time.

For this to operate efficiently, design considerations must be implemented to consider the availability of Digital Workers to catch real-time attended commands. This introduces the concept of polling, scheduling, and digital worker roles like an unattended configuration. I will first zoom into how a polling process is setup and then expand to broader considerations around scheduling and roles.

Polling (aka. looping) for Work

Most Blue Prism customers today have some form of attended automation already running but may not think about it from this perspective. While short circular paths have many uses outside this model, when reviewing a demo or process design, this pattern is almost always found within the first few steps of a process.

BP Foundation Training – Section 3.1

While a large portion of enterprise automations will often be setup to run on schedulers, some are searching for an event to occur outside of Blue Prism. For example, a Digital Worker may be constantly monitoring an email box or SharePoint site for a new email or document. When a new record is found, this Digital Worker can then directly perform a process associated to the new file. Alternatively, the Digital Workers can extract information from the file and add new items to a work queue, so that other Digital Workers can perform the work. Polling (or looping) for work is a common design for these two processing paradigms.

[Video Demo] Lou Bachenheimer's Raffle Demo – This demo polls an Outlook email box, adds emails to a work queue, checks for open work queue items, checks for duplicate emails, utilizes the Microsoft Computer Vision skill to describe an image attached to the email, and replies through Outlook with the image description to the original sender.

Polling an Email Inbox

This simple process example is polling an email inbox, and through the “instructions received” decision stage, determines if email should start a process. In this example, the “Start Process” stage calls a sub-page according to the email instruction. The same technique can be utilized to poll for a UI change, file or enterprise system update.

Simple Email Inbox Poll - Initiate Sub-Process

Alternatively, the “Start Process” stage could be replaced with a stage to start a separate Process.

Simple Email Inbox Poll – Initiate Separate Process

The “Start Process” stage could also be replaced with a stage to add items to the Work Queue for other Digital Workers to process. There is much more information on Work Queues below.

Simple Email Inbox Poll – Add to Work Queue

The “Check Inbox” Action shown in each example utilizes Blue Prism’s default MS Outlook Email VBO. This Visual Business Object (VBO) includes an array of actions for sending/receiving email, moving emails, manipulating attachments, etc.

Check Inbox Action Properties

The “Add to Queue” stage shown above uses Blue Prism’s native VBO and includes a wide array of actions.

Add to Queues Stage

Note that these are very sample design and additional logic needs to be implemented to check the email inbox, manage available resources and validate parameters.

Polling a Work Queue

This process beings by collecting instructions from a Work Queue. This design accommodates different types of triggers from different sources to be used at the same time.

This simple process example is polling a Work Queue to “Get Next Item”, and once the catch is confirmed through a “Got Item?” decision stage, the “Start Process” sub-page is started.

Simple Work Queue Poll

Work Queues Business Object Actions

Attended Scheduling?

All RPA platforms include a scheduler which can execute processes at specified times and repeat their execution at pre-defined intervals. Most common RPA platforms also integrate calendars to cause the schedule to run only on working days, skipping specific certain weekdays and/or public holidays.

Blue Prism supports the assignment of work statically (scheduled) or dynamically (active queue management). Active queue management can consider factors such as priority of the process, associated SLAs, historical execution time, current amount of work in the queue, availability of other run-time resources, and more in order to decide how to dynamically assign/reprioritize pending work items. Blue Prism Cloud’s machine learning-based IADA builds on these capabilities by monitoring SLA requirements and real-time fluctuations in business volumes to orchestrate Digital Workforce assignments.

Unattended automations are always running on schedules. Schedules can also be utilized with off-desktop attended automations to balance hardware/software resource utilization with SLA requirements.

A Digital Worker can continually search external systems for new work from a large team of human users. This may be valuable where near-instant SLAs are expected, such as contact center or chatbot interactions. However, a large portion of automation related activity does not require an instant response. Consequently, the Blue Prism scheduler can be used to run processes periodically instead of continuously, so that Digital Workers spend more time performing work as opposed to waiting for work. This allows the Digital Workers to be utilized for other processing while the Work Queue accumulates requests.

Blue Prism Schedules

Blue Prism already tracks the amount of Digital Workers needed to perform a regularly scheduled activity such as those related to month-end-close, and active queues can show how many Digital Workers would be necessary for a close in 2 days vs. 3 days. Similarly, some study of process demand should be conducted either manually or through process mining tools (ex. Celonis Optimizer for Blue Prism). Look for demand spikes to track how frequently processes may be triggered. For example, AD unlocks and password reset processes are likely to be called in a dense window on Monday mornings. Consequently, a higher number of Digital Workers should be available to directly poll for these requests via work queues, emails, or chatbots on Monday morning.

Unless a Digital Worker needs to constantly run, then schedules can be used to start processes at specific times. These may be Digital Workers assigned to feed Work Queues or Digital Workers assigned to move between Work Queues. In either case, a Digital Worker should not be sitting idle if avoidable. In production tests, start by assigning a higher volume of robots than expected to catch a triggered process or poll a work queue. It is better to oversubscribe licenses in order to meet human expectations of SLAs to start. As actual processing volumes are tracked, then taper down Digital Worker assignments through schedules to only slightly oversubscribe Digital Workers to queues that require near real-time processing and gauge human tolerance for queues that do not mandate near real-time response.

Digital Worker Roles

While on-desktop attended configurations for RPA/RDA associate a license to an active human user, and perform work under the restricted context of that human user, off-desktop attended configurations allow for much more flexibility around license consumption. In Blue Prism, this configuration allows one licensed Digital Worker to work with many humans instead of licensing 1 robot for every human. This licensing component also extends to other enterprise systems as leading providers of ERP, CRM, BPM, ECM, and HRIS platforms add clauses to agreements which require separate licenses for human and BOT users.

Design considerations for both off-desktop attended and unattended configurations of Blue Prism can be similar to thinking about how a human workforce would be setup. Which is the most logical setup for based on the frequency of your processes, SLA requirements, network traffic, license, and hardware utilization?

• Should your Digital Workers separate roles similar to a receptionist and clinician at a hospital? One Digital Worker acts as a “triage bot”, specifically focused on registering patients for their visit, while other Digital Worker perform specific process work.
• Should your Digital Workers share a broader role, similar to a grocery store employee running a checkout line. The one Digital Worker performs all steps end-to-end.

Fortunately, Blue Prism Digital Workers are more flexible than their human counterparts, and don’t need a decade of medical education to change from the triage to clinical role. However, each active Digital Worker consumes a Blue Prism license and infrastructure, so you also don’t want the entire Digital Workforce attending empty checkout lines when there is other work in the store that could be done during slow hours.

Please see the following resources for training related to this post:

• Foundation Training : Section 3 – Circular Paths, Collections and Loops
• Guide to the Scheduler (BP Portal)
• Dynamic Scheduler Examples (BP Portal)