Build Procedure

This page describes a procedure for building Blue Prism solutions. It is not the only procedure but it is one that has been honed through many years of practice and is proven to be successful.

Building Business Objects

Designing and creating business objects is relatively easy when each object page has a specific, understandable purpose. As well as discouraging single ‘mega’ objects in favour of a series of smaller objects, Best Practice also advises to try and keep object pages simple. Complex, multipurpose pages tend to be harder to build, test, maintain and importantly, re-use.

Conceptually, the pages of a business object can be thought of as ‘mechanical parts’ that are used to create bigger machines, i.e. processes.

Although it’s normal to start building a solution by creating objects, a common beginner’s mistake is to spend too long in Object Studio before starting on the process, and this strategy is almost certain to lead to problems. The risk in concentrating on objects is that the developers forget that all the parts need to work together, and even though the individual parts may seem perfect, they don’t assemble to form a robust construction.

When this happens, there is a potentially large collection of components that don’t fit. The process has errors in many places, and it can be difficult to know what to correct. Furthermore, the project deadline is approaching, and the process does not yet work.

Process Building


The number one requirement when first creating a Production process is to use a template. A template saves time, includes Best Practice and propagates a common design. Example templates can be found here and delivery teams are encouraged to create their own versions.

Having more than one template is not uncommon - although all processes have similarities. There are a handful of common RPA solution ‘shapes’ and having a template for each would make sense. For example, many Blue Prism processes follow one of these generic types.


Another key requirement is to use a work queue. Very occasionally there may be a valid reason for not using a queue, but this is rare. This guidance assumes the reader has completed the Foundation Training course and is already familiar with the guidance on work queues.

The Five Part Pattern

Almost any Blue Prism process intended to execute repetitive tasks can conceptually be reduced to a Five Part Pattern​, as shown below.

5 Pattern

Repetition implies a loop of some kind and so we can perceive the parts of the pattern as follows:

  • Part 1 defines the start of the process, before the looping has begun.
  • Part 2 covers the steps after leaving the loop, when the process comes to an end.
  • Part 3 is the logic required to complete the loop before starting the next task.
  • We expect to encounter problems, so Part 4 is the recovery logic, bringing the process back to the happy path.
  • Finally, Part 5 is the actual ‘work task’ logic where again, we anticipate that some tasks will result in exceptions and follow the unhappy path.

Visualising an automated process in this way can help shape the solution design, dictate the build sequence and inform the test approach. And by starting with a template, the construction of the process can be broken down into phases.

Build Phases

Process Debugging

The key to debugging a process is the ability to locate the source of the problem.

As any Blue Prism developer should know, the work queue provides a high-level view and the session log provides a low-level view of exceptions. With this in mind, effort should be made to ensure the information recorded in the queue and logs is useful. In particular, exception types should be carefully chosen, and exception details should be accurate.

We all know Copy and Paste is a great time-saver during development, but care must be taken to avoid duplicating exception information. A ‘narrative’ of a queue item’s progress through a process can also be recorded to assist investigation into problems. The Status, Tags and Item Data collection can all be updated with trace information.

Recall however that Best Practice mandates that Tags must not be used to carry case-specific data (such as a Client ID or address) and should only be used for the categorisation of queue items. Excessive numbers of unique Tags have been known to put undue strain on the database.

Similarly, the logging level in a diagram can and should be adjusted. Note stages can be useful for recording a ‘marker’ in a session log. Screenshots, both as temporary aides or as part of exception handling, can also be helpful when it’s difficult to witness a problem.

When problems do arise, it can be useful to have the ability to identify, isolate and replicate the type of input/data/case/scenario/time/whatever that is causing the issue. And with practice, a developer can learn to prepare a process diagram in such a way as to make this easier.