Solution Design

A Blue Prism process needs to be much more than a series of manual steps executed automatically. It needs to be robust enough to work unattended, be able to recover from unexpected situations and work concurrently on multiple machines. This realisation is often missed when learning to design a Blue Prism solution.

Designing for unattended automation

After focusing on the definition of the manual process in the PDD, a common mistake is to envisage the automated process merely as a linear sequence of work steps.


This is too simplistic because the objective of the process is to work one case after another, and after completing one case it will need to return to the start position in readiness for the next. So the process will need to maintain control over the applications and data it is using, and these reset steps may well involve navigating back to a main menu screen and resetting variables.


At some point the process will also need to break out of this loop, and often this is simply when there are no more cases left to work but the decision could also be made for other reasons, such as when the end of the working day is reached.

It is also likely that there will be additional steps before and after the working loop. Examples of preparation steps are things like logging in to applications and gathering input data. The finishing steps could be something like logging out and closing down the applications, creating a report or sending an email notification.


To illustrate this consider the following process constructed using the Blue Prism Basic Template. The three areas outside of case processing (work) are clearly marked.


Another common oversight when designing a process is to assume that it will never encounter any problems and always stay on the ‘happy path’. Again, this is unrealistic and recovery steps should be included to cater for the ‘unhappy path’ logic, as shown below in orange.


Here exception handing is employed to make the process recover from unexpected application behaviour, so that cases can be set aside for manual investigation or if necessary, reworked by the process. The recovery logic may also need the ability to restart applications for the process to continue working.

Solution Types

There are different types of automated solution that can be applied to a manual process. Consider this abstract process, comprised of manual steps 1 to 9.


Solution Layers

A Blue Prism automated solution can be perceived in layers, starting with the process layer, down to the object layer and the application model, and through to the application layer.


The role of the process layer and the object layer can be confusing at first, but in essence an object should be seen as a tool that provides a process with the mechanics to manipulate the application. Business logic, rules and decisions should, in general, be in the process.

Design Essentials


In simple terms, recoverability is the capacity of the solution to handle problems and return to normality. It is naïve to assume that the happy path is the only possibility and provision should always be made to attempt recovery from unexpected situations.

Scalability and Reusability

Workload Management

Data Management



The client’s requirements may stipulate that certain events should be alerted, and as such the design should make provision for when, where and how these notifications are to be issued.

For example, the Control team may want to be notified of key events like a process termination. Perhaps a process completion should be alerted to the Operation so that they can pick up from where the automation finished. Or, more seriously, maybe an SLA breach needs to be alerted to trigger a contingency plan.

Whatever the reason, how the solution is to communicate needs to be considered as part of the design. Email is typically the preferred method but SNMP messages to a helpdesk could also be used.  Alternatively, notifications could be issued as updates to another application such as a workflow tool or MI database.

Design Procedure

The delivery of a Blue Prism solution into a production environment follows a standard path of Define- Design-Build-Test-Implement, familiar to many IT projects. Blue Prism offers a proven design methodology with accompanying document templates, and trainees are introduced to these as part of the Life-cycle Orientation module.

These templates are not prescriptive however, and some clients are more comfortable adapting their own methodology and documentation to work for RPA. It is the purpose of the documentation that is important, the documents themselves are merely vehicles - for defining requirements, exposing detail and for reaching agreement.

Design Review