Guide to Creating a Blue Prism Process

BLUE PRISM LEARNING

Version: 1.1.001

For more information please contact:

[email protected] | UK: +44 (0) 870 879 3000 | US: +1 888 757 7476
www.blueprism.com
Contents
Introduction ..................................................................................................................................................................3
Training Prerequisites ...............................................................................................................................................3
Process Build – Step 1: Validate Pre-requisites .............................................................................................................4
Project Prerequisites .................................................................................................................................................4
Process Build – Step 2: Process Template .....................................................................................................................6
Process Build – Step 3: Implementing the Process design ............................................................................................7
Process Main Page: ...................................................................................................................................................7
Adding Control – The Stop? decision ........................................................................................................................8
Robustness ................................................................................................................................................................9
Other Process best practices...................................................................................................................................11
Process Build – Step 4: Test as you build ....................................................................................................................14
Process Build – Step 5: Peer Review ...........................................................................................................................14
Process Build – Step 6: SME Verification .....................................................................................................................15
Process Build – Step 7: Production Readiness.............................................................................................................15

The information contained in this document is the proprietary and confidential information of Blue Prism Limited and should not be
disclosed to a third party without the written consent of an authorised Blue Prism representative. No part of this document may be
reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying without the written
permission of Blue Prism Limited.
© Blue Prism Limited, 2001 – 2017
®Blue Prism is a registered trademark of Blue Prism Group plc
All trademarks are hereby acknowledged and are used to the benefit of their respective owners.
Blue Prism is not responsible for the content of external websites referenced by this document.
Blue Prism Limited, Centrix House, Crow Lane East, Newton-le-Willows, WA12 9UY, United Kingdom
Registered in England: Reg. No. 4260035. Tel: +44 870 879 3000. Web: www.blueprism.com

Commercial in Confidence Page 2 of 16

Introduction
This guide is intended to supplement the Blue Prism® Foundation Training course and other mandatory training
modules. It is aimed at students who are beginning to put their education into practice.
This guide will walk you through the main considerations when creating a new process in Process Studio

Training Prerequisites
Before creating your first process the following mandatory training should be completed:
 Blue Prism Foundation Training course
 Guides and modules related to Exception Handling and Work Queues
 Blue Prism Basic Template Instructions should be read and understood
 Blue Prism Lifecycle Orientation solution should be imported and understood

This guide does not cover the Object Studio build of a solution. For training related to how best to build your
Objects please refer to the following in the Portal:
 Blue Prism Foundation Training course
 Object Layer Design tutorial
 The Object Design Instruction (ODI) example available in the Lifecycle Orientation Sample Delivery
Documents
 The completed objects available in the Lifecycle Orientation solution which should be imported into your
own environment and understood
 The interface specific guides available in the Learning/Guides area of the Portal

Commercial in Confidence Page 3 of 16

Process Build – Step 1: Validate Pre-requisites
Before you can start building your Blue Prism process, you need to validate everything is in place that you need to
be able to create a solution that meets the business requirements.
Project Prerequisites
Work should not start on creating your process until the business process you want to automate has been correctly
defined and the designs outlining what you need to build have been created and signed off.

Delivery Methodology Pre-requisites:

 Process Definition Document (PDD). The PDD defines the business process at a granular key stroke level
and describes all the business rules and decisions that are made. The PDD should be signed off as correct
by the business.
 The Solution Design document (SDD). The SDD is a high level design document that describes how the
entire solution is going to be built. The SDD should be peer reviewed by an experienced Blue Prism
developer or mentor, and approved in accordance to the delivery methodology in your organisation.
 The Process Definition Instruction (PDI). The PDI is a low level design document that describes exactly how
the process should be built including Work Queues, Environment Variables, Alerts, etc. The PDI should be
peer reviewed by an experienced Blue Prism developer or mentor, and approved in accordance to the
delivery methodology in your organisation.
Examples of all these project delivery documents can be found in the Lifecycle Orientation training sample delivery
documents.
Agile Methodologies:
If your organisation is using an Agile Methodology for Blue Prism development the requirements still need to be
defined and your solution still needs to be designed.
It is a common misconception of those inexperienced with agile, who choose this methodology on the basis of
thinking that their project can be delivered more quickly and easily by avoiding documentation. But agile is not an
excuse for skipping documentation.
Agile is an iterative development methodology and when done correctly it will still include agreed definitions of
what needs to be built and a design of how it going to be implemented in each delivery iteration.
Environment Pre-requisites
As well as the necessary approved documentation being in place, before you can start work on building your
process ensure everything you need is in place for you to be able to create a solution that is correct.
 A development environment exists that matches the production environment as closely as possible (same
operating system version, same browser version, same system versions, same screen resolution).
 Blue Prism product is installed and working. You can sign into the Blue Prism product.
 Test data exists which can be used during your process build so you can step through and run your process
end to end.
To validate that the development environment is fit for purpose, you should be able to 'smoke test' the
environment by manually working the business process that you are going to build end-to-end.

Commercial in Confidence Page 4 of 16

People Pre-requisites
You cannot create a Blue Prism process without being able to contact people with expertise in either the business
process you want to automate or the technical environment in which you are working
The following people should be available to you:
 A Subject Matter Expert (SME) is available to you during your process build. The SME is someone that
knows the business process very well, ideally having worked the process manually. The SME needs to be
available to you when you have a query about the business process and also to validate the process you
create prior to User Acceptance Testing (UAT).
 You should have contact details for who to contact in the IT department if there is an issue with your
development environment, such as a connectivity or network fault or a system that is unavailable to you.

Commercial in Confidence Page 5 of 16

Process Build – Step 2: Process Template

All processes built in Blue Prism MUST start with a Blue Prism Process Template. Using a process template ensures
the following benefits:
Why use a Process Template?
 Save time: the Process Templates have
already made a start in building your
Process logic for you.
 Make support easier: by using Process
Templates everyone's Processes looks
the same, making them easier to
understand.
 Ensure best practice: the Process
Templates already contain all the work
queue, exception handling, and stop
decision logic that are outlined in this
guide.

Your own organisation might want to expand on the standard Process Template provided by Blue Prism to add in
common alerting or credentials logic that is to be used for all your solutions.
Because of the importance of always using a Process Template the first thing to do when starting to build a new
Process is to open a Process Template and use the Save As menu option to save the template as the name of the
new process you want to create.

Commercial in Confidence Page 6 of 16

Process Build – Step 3: Implementing the Process design
Once you have saved a copy of the template as your new process you can start amending it to add your process
logic in accordance to the peer reviewed PDI design document.
This section explains many of the best practices that should be implemented in your processes and which are
enforced by your use of a Process Template.
For a working example of a process that implements all these features you should import and review the Create
Quotes Process that is distributed as part of the Lifecycle Orientation training solution.

Process Main Page:

Your Main Page should be a simple high level flow diagram
that uses sub-pages
On the right is the Main Page of a process with most of the
process logic placed in sub-pages
Standard Sub-Pages:
 Start Up – a sub-page that launches and logs into
applications
 Close Down – a sub-page that logs out and exits
applications
 Populate Queue – a sub-page that loads work from a
source into a Blue Prism work queue (this logic could
also be placed in a totally separate Blue Prism
process)
 Work Pages – multiple 'work' sub-pages for
navigating and updating the systems

Why use Sub-Pages?

It is easier to quickly understand what a process does just by
looking at the Main Page.

Commercial in Confidence Page 7 of 16

 Adding Control – The Stop? decision
On the right is the main page of a process with a
Stop? decision stage added.
The Stop? decision evaluates environment
functions and session variables after each Work
Queue item has been worked?
Stop? Decision session variables:
 Stop Time – a time session variable that
is set to the time after which the
process should stop processing work.
 Stop After Items – a number session
variable indicating how many more
items to work before stopping. This is
useful if you want to test or run only a
set number of cases.
 Stop ASAP flag – For Blue Prism version
4.2 and earlier a flag session variable to
indicate if a process should stop after
working the current case (superseded in
version 5 by the IsStopRequested()
function)

Why use a Stop? decision?

The team controlling the resources can now easily alter the running of a process session from within Control Room.
Every Process should have a Stop Time, a process must never be configured to run 24/7 without stopping.

Commercial in Confidence Page 8 of 16

Robustness
Basing your process on a Process Template ensures the implementation of best practice exception handling.
The best practice exception handling includes the following:
 Retry exception handling logic on sub-pages.
 An Exception Block on the Main Page around sub-pages that interface with systems.
 A Mark Item As Exception sub-page that terminates the process if the same system issue occurs for
concurrent work items.

Robustness: Sub-Page Retry Loops

If an exception occurs on a sub-page it could be a one-
off issue (i.e. a network timeout) that would be fixed if
the process flow simply tried again.
Sub Page Retry Loop:
All 'work' Sub-Pages should do the following:
 Catch any exceptions with a Recover stage.
 Evaluate the exception with a Retry? decision
 If there has been less than 3 attempts and the
exception is a type you want to retry, loop
around and try again.
 If trying again, perform actions to 'tidy up' the
system being used, in the flow on the right we
simply restart it but you may need to re-
navigate back to the correct system state.
 If not trying again, 'throw' or 'preserve' the
exception up to the Main Page.
Why is this better?
For one-off application errors, or systems that have
reliability issues, the retry loop improves the changes
of a Work Queue item being successfully worked.

Commercial in Confidence Page 9 of 16

Robustness: Main Page Exception Block
If an exception 'bubbles up' to your Main Page from a Sub-
Page we don't want the process to terminate.
Main Page Block:
In the flow on the right we have added the following:
 A block around the main work interface sub-pages,
with a recover stage.
 A Mark Exception sub-page that will contain your case
exception handling logic (marking the Work Queue
item as an exception).
 A Resume stage so that the flow can continue on and
attempt to work the next Work Queue item.
Why is this better?
All Work Queue items should have a result set by the process,
either Completed or Exception.
The process should not just terminate if one case has a
problem.

Robustness: Consecutive Exceptions

If the same exception occurs for every Work Queue item a
process attempts to work, it is best to terminate the
process so that a Controller can investigate the issue.
Mark Item As Exception:
The Main Page block calls a Sub-Page called Mark Item As
Exception that does the following:
 Compares the current exception to the outcome
of the previous case worked.
 If the current exception also occurred on the
previous case it increments a counter.
 It marks the current Work Queue item as an
exception.
 It Terminates the process ('throws' an exception
not recovered on the Main Page) if the same
exception occurs repeatedly for a configurable
number of items.
Why is this better?
If a system is not available or has changed we do not want
a process to attempt every Work Queue item and mark all
items as Exceptions.

Commercial in Confidence Page 10 of 16

Other Process best practices
Work Queues:
All Processes must use a Work Queue. Even for business processes that are a run once linear rather than multi-
case iterative, or processes that get work from a BPM worklist that manages multi-users, a Work Queue should still
be used as a method of recording case time and exceptions.
Work Queue Tags:
 Work Queue tags are easily search in Queue Management and are reported on the standard Blue Prism
Performance Report.
 Tags are useful to get total numbers of different work or case types that have been processed.

Work Queue Status:

The status is a useful way of recording how far through your process a Work Queue item has been worked.
Recording the status can then be used to:
 See from the Queue Management screen the progress of an item.
 If an item is to be re-worked following an exception (for example, by using the 'Force Retry' option in the
Queue Management items table) the Status could be used to skip steps in the process flow that have
already been completed for that item. This is especially important for multiple-update processes where
some updates should never be repeatable.
 If an item is reported as an Exception to be manually worked, the manually team can use the Status to
know how much of the work has been completed. This ensures that the benefit of a partially worked item
is realised.

Environment Variables:
Environment variables should always be used for storing configurable information such as:
 Network Paths
 Email, database, or web service configuration
 System configuration such as website URLS

Commercial in Confidence Page 11 of 16

Credentials:
Username and Passwords to access systems should never be saved in the initial values of data items. System
access information should always be stored in a secure and encrypted store such as the Blue Prism Credentials
feature.
Process Alerts:
Ideally a Blue Prism solution should not need to be constantly monitored in Control Room to ensure it is still
running without any issues.
To decrease the management your solution requires a form of Process Alerts could be built into your process to
inform the Process Controller team if something is wrong. This can be as simple as sending an alert before your
process terminates.
It is recommend that an organisation decides upon a preferred method of sending Alerts that is used for all
processes that are developed.
Common methods of sending Alerts are:
 Blue Prism Process Alerts. These can be configured in the Security – Users are of the product. To receive
alerts you need to be sat at a computer with the Blue Prism product running and connected to the
environment in which the Alert was raised.
 Emails. Many clients use one of the available email interfaces to send alerts to the Controller team.
 CRM or Workflow systems. Some clients raise a support ticket in an existing workflow system.
 Other monitoring tools. Some clients have existing monitoring tools that they use to send Process Alerts.
How alerts are sent will depend upon options available to interact with that tool set.

System Unavailable Exceptions:

In the Blue Prism basic template, a process simply terminates if the same System Exception occurs repeatedly.
A more robust but complex option that can be implemented is to recognise if a system is unavailable and instead of
terminating, send an Alert to the Blue Prism Controller team and periodically attempt to restart the unavailable
system until the System can be started available again.
The System Unavailable Exception type is thrown when an application cannot be launched.
Any polling logic that periodically attempts to launch the system should include a Stop? decision to check if the
Controller has requested that the process should stop or if the stop time has passed.
Your System Unavailable logic on your Mark Item as Exception page may look like the following flow:

Commercial in Confidence Page 12 of 16

Commercial in Confidence Page 13 of 16
Process Build – Step 4: Test as you build
One of the most common issues raised by new developers creating their first Blue Prism solution is that "it works in
Process Studio but does not work in production when I run it from Control Room".
This problem is almost always the result poor wait stage logic in objects and indicates that the developer has not
adequately tested the solution running at full speed during the Process build.
To reduce the risk it is recommended that the developer working in Process Studio constantly tests the solution
running at full speed as action stages are added. This ensures that any issues with an object interfaces are found as
early as possible rather than waiting until the solution is handed over for UAT testing or Production roll-out.
For example, this image shows a process flow after only the Start Up and Close down pages have been completed.
Even though only these two pages are finished the developer should run the process at full speed just to test that
those two pages and the objects they use work correctly.

Once the Start Up and Close Down pages the developer will progress with a continuous cycle of adding a bit more
process flow logic and testing at full speed.

Process Build – Step 5: Peer Review

Every Process built in Blue Prism MUST be Peer Reviewed by an experienced Blue Prism developer or mentor other
than the developer that created it. A peer review is not there to undermine the ability of the developer, it simply
acknowledges that we all make mistakes and an experienced second pair of eyes is always beneficial.
The review should ensure that all best practice lessons taught in Blue Prism training have been implemented, and
that your own organisations internal Blue Prism conventions are adhered to (such as naming conventions, alerting
methods, security policies, etc.).
Blue Prism provides the following on the Portal to support internal Peer reviews:
 Development Best Practice guide
 Peer Review Checklist

Commercial in Confidence Page 14 of 16

Peer reviews of development work should always take place, but they are especially valuable as part of the
mentoring approach that should be in place for all new Blue Prism developers.

Process Build – Step 6: SME Verification

One of the many benefits of the Blue Prism product is its use of flow diagrams that are readable to business users
and that can be easily stepped through and discussed with a process SME.
Blue Prism recommends that a verification step is included in your delivery methodology to validate that the
solution that has been built actually performs as required. This verification step reduces the risk of the process
definition being incorrect or incomplete.
To verify your process with an SME the following needs to be done:
 Schedule time with an SME between completing your Process build and UAT testing
 Sit with the SME and step through your solution in Process Studio.
 Discuss each step in your process with the SME to validate it is correct. Pay specially attention to business
rules and decisions, and ensure that any update screens in applications are correctly completed.
 If the SME notices anything incorrect or missing from your solution, note it down to add into your process
flow later. If any major changes required the Project Manager should be informed and the changes should
be added into the PDD and signed off by the business process owner.
 For large or complex business processes you may need to have multiple iterations of SME Verification
sessions after you have made the suggested changes until no more changes or corrections are identified.

Process Build – Step 7: Production Readiness

Before your process can be signed off as complete you need to ensure the following:
No reported errors
Process Studio includes an error checking feature that should be used to ensure your process has no obvious errors
in it. Fix any reported errors until the feature reports that there are no errors remaining.

Turn off unnecessary logging

Blue Prism session logging can generate a very large amount of data. Best Practice is to do the following:
 Turn off as much logging in your process as possible, only leaving enough logging turned on to be able to
easy trace the route each case worked has taken through your process flow. Logging is usually left turned
on for Decision and Choice stages.
 Turn off any logging on Stages that use customer data. It is important that customer data is not stored in
session logs.
 Turn off logging anywhere that might generate large amounts of log data. Look for loops through large
datasets or stages with lots of input or output parameters.

Commercial in Confidence Page 15 of 16

Deployment Documentation
Before you can hand over your process as complete you need to ensure that all documentation required by your
organisations delivery methodology have been completed.
If your solution has changed during your Process development the SDD and/or PDI documents should be updated
to reflect this and the changes should be signed off.
The Robotic Operation Model area of the portal includes the following templates:
 Blue Prism Release Note Template – a sign off document to ensure the agreed methodology has been
followed and permissions given for your completed solution.
 Operational Handbook Template – this is a handover document from the developer to the Controller team
that is going to be running and managing the process in production.

Commercial in Confidence Page 16 of 16