Designing Blue Prism Processes for Human in the Loop

A picture containing appliance, dryer

Description automatically generated
Connecting RPA with Humans

Blue Prism is well known as an enterprise grade, unattended Digital Workforce Platform.  Given Blue Prism’s strength in unattended RPA, there’s a misconception that Blue Prism cannot do attended RPA as well. 

In fact, Blue Prism is perfectly capable of supporting Human in the Loop automation. It just requires Solution Designers to consciously design user interaction into their Blue Prism processes.  In this article, we will explore some Blue Prism Process design considerations and describe some high level approaches on how to add human-robot interaction to your Business Processes.

Design Considerations

When designing for Human in the Loop, think about the characteristics of your Business Process and Blue Prism environment.

Input Time Sensitivity

There are three main ways in which input could be time sensitive:

  1. The input data is time sensitive.  For example, the input could be an SMS or a security token that expires after 60 seconds
  2. The automated application is time sensitive.  For example, the application must receive input within 60 seconds, or it will time out
  3. The Business Process is time sensitive (Service Level Agreements).  For example, if work must be completed within 30 minutes of starting, then waiting for the User’s input can become a bottleneck for the SLA if inputs to the process are not sent in a timely manner

When inputs are time sensitive, it’s important to notify users that input is needed in real-time. Providing a user-friendly way to enter data through developing custom forms or interfaces will speed up input times as well.

Time sensitive input processes lend themselves better to a “polling” style of design.  If input is not time sensitive, then either a “polling” or “multi-process” design can be considered.

A close up of a logo

Description automatically generated

User Access to Blue Prism and the Environment

This affects process design by allowing for different options to get user input into Blue Prism.

  1. Do users have access to the Interactive Client or Runtime Resource machine?  If so, startup parameters and the CLI can be considered
  2. Do users have access to the Blue Prism network, or devices that are connected to the network, such as FTP, email, database or network storage?  If so, then these connected data sources can be used to store input for Blue Prism to read
  3. Can users store their input online, and can the Blue Prism environment download information from the Internet? If so, consider using online forms or API calls connected to Web Services

License Usage

Another factor that will affect the design choices that are available to you are the number of Blue Prism licenses available in your environment. The affect of certain designs on the license usage will be discussed further in the sections below.

High Level Design Approaches

Multiple Process Design and Startup Parameters

Startup parameters can only be input into Blue Prism before a Process is run.  Specifying startup parameters is typically done by a Process Controller.  However, this can be done by other users outside of the Interactive Client as well, allowing other people to control what is passed in before a process is started.

If data needs to be input at multiple points inside a Business Process, see if the Business Process can be designed as multiple Blue Prism Processes.  Then, user inputs can be converted into startup parameters for use in the next portion of the Business Process. 

For example, if you need to have user input twice during the middle of Process execution, think about designing this as three Blue Prism Processes:

A screenshot of a cell phone

Description automatically generated

The end of the previous Blue Prism Process should notify the necessary people that they need to provide input for the next Blue Prism Process that should be started. Once the input has been received, we can either start the next Blue Prism Process if it isn’t running yet, or add it as a new Work Queue Item if it is running already.

A multiple process design makes sense when inputs are not time sensitive.  Instead of waiting for input, this design allows for other Work Queue Items to be processed.

Input time sensitivity for this design can be improved through more frequent scheduling of the subsequent Processes and executing them on more Runtime Resources. In doing so, the time gap between when input is sent from the User, to when it is picked up in Blue Prism can be reduced.

It is important to consider the impact on your license usage and SLAs in this kind of design, unless you never intend to run multiple sessions of the Blue Prism Processes at the same time.

A downside of using multiple Blue Prism Processes is that gaining a view of the overall progress of the work for reporting becomes more complex.

A Blue Prism Process can be started, with startup parameters specified as input using:

  • The Interactive Client, from either the Control Room or Scheduler
  • The Command Line Interface (CLI).  You can start and schedule Processes from the CLI.  The in-product help, provides an example on how to start a Process with startup parameters:

AutomateC /run "Process 2" /resource YourPCHostName /user admin mypwd /startp "<inputs><input name='Comment' type='text' value='Hello World' /></inputs>"

  • Web services.  See page 21 of the Web Services Guide, which is available on the Blue Prism Portal. The use of web services also has implications towards the number of licenses used. A detailed discussion on this can also be found in the Web Services Guide

Many customers opt to custom build graphical interfaces to simplify user input into Blue Prism Processes.   These are typically GUI programs that will feed input parameters to the CLI, or web forms (such as Microsoft Forms) that will pass input into Blue Prism using web services.

Single Process Design and Polling

If the Business Process should be designed as single Blue Prism Process (for instance, if input time is sensitive), then user input cannot be taken in using startup parameters.  There should be a polling loop to wait at each point that needs user input. 

The polling loop will check for the presence of input data and either sleep or continue with the process, depending on whether the input is received.  Remember that your polling loop should have a maximum waiting time. This is to prevent an infinite loop from occurring in your process.  Inside your polling loop, input data can be read from a variety of sources:

  • Network or FTP files, such as plain text or Excel
  • API call responses
  • Chatbots messages
  • Email subject and body
  • Database queries
  • SMS

A downside to this type of design is that it ties up your Runtime Resource while waiting for user input. What you get in return is a fast continuation of the process after the input has been received.

Once again, some customers choose to build custom UIs to facilitate the input of data back into Blue Prism.

In a polling design, your Business Process waits for input while executing the process. The number of licenses used is simple in this case. It’s the number of simultaneous polling processes that you have running at the same time.

If the Business Process doesn’t have an urgent SLA, or if you do not expect the user to be able to provide input quickly, you can consider a Single Process design without polling.  Instead, think about deferring the Business Queue Item if the user’s input is not received and use Work Queue Item Statuses to skip process steps until the “waiting for input” step.  This will allow other Work Queue Items to be worked on while waiting for the input data.

Third Party Services

There are several third party services that can be used to facilitate human-robot collaboration.  One such example is TrustPortal.

These platforms (typically web based) allow RPA teams to:

  • Perform user management
  • Set access control, i.e. allow access to only the processes that a user should have access to
  • Define and create forms used to input data for a specific process
  • Notify to users that input is needed
  • Present forms to users to take in input
  • Translate the user input back into a format that can be consumed by Blue Prism
  • Notify users on any responses received back from Blue Prism

I wouldn’t be surprised if these services use similar process designs to the ones I’ve mentioned above.  However, if you don’t have the time to create your own solution, or if you have heavy Human in the Loop requirements, consider using one of the turnkey solutions that are available in the market.