Note: You are looking at a static snapshot of documentation related to Robot Framework automations. The most recent documentation is at https://robocorp.com/docs

The Process Definition Document

Process definition document: A tool to help to document existing processes

Once a process has been identified as a good candidate to be automated, it is time to document it in detail. This documentation will then serve as the basis for implementing the software robot that will take over and handle the process in the future.

During this requirements gathering phase, the software robot developer needs to work in close contact with the business side to get familiar with the current process and the business domain in which it is executed. This often means sitting next to the user when the process is run, asking all relevant questions, and exploring all possible cases.

The result of this analysis phase is collected in a document called Process definition document (PDD), which is then shared with all the relevant people involved, approved, and signed off.

Download our template for your process definition documents

We are happy to share our process definition document template with you that you can use freely in your next automation project. You can find the process definition document in two formats:

The process definition document template includes indications about how you should fill the various sections. Remember to delete the explanation texts and best of luck with your automation projects!

Good luck with your automation project! Are you planning to use the Robocorp automation stack in it? We provide open-source development tools that developers love and a new and cost-effective way to run your robots in the cloud. Learn all about it on our website!

Contents of the process definition document

What should a process definition document achieve? A good PDD document should provide clear answers to the following questions:

What is the process used for, and what is its end goal?
What are the steps involved in the process? Are there any decision points?
Who is in charge of the process?
By whom and how often is the process executed?
What are the systems involved in the process?
Does the user need special authorization or roles to run the process?
What are the possible problems and exceptions that can happen during the procedure? How does the user handle those?

A practical example of a process definition document

To show a practical example of a PDD document, let's examine a use case, inspired by our Web store order robot. In this imaginary clothing e-commerce company, "Swag Labs Inc", some of the customers prefer to place orders by phone. Someone needs to then log into the site and place those orders manually on behalf of the customers.

This process is an excellent candidate to be automated, so let's create the Process Definition Document for it!

You can download the test case PDD document here and follow along.

Process name

First of all, we need to come up with a name to identify the process. The Business might have a name for it already. In our case, we have gone for "Batch phone order processing".

Document metadata

Versioning

You should set up your process definition document so that it is easy to update and to archive. If you are not using a versioning system, we recommend at last to add the version in the file name and adding a table inside the document to show the current and previous versions.

Sign off

The information contained in the process definition document is part of the specification that will be used to develop the software robot, so it must be verified to be accurate and signed off by the business side.

In our example, we might require the sign-off of the person responsible for orders at Swag Labs.

Contributors

List the people that have collaborated in creating the process definition document. It will be useful to record the key people on the business side that know about the process also in the future.

In our example, we would list ourselves and the Swag Labs employees that helped us collect the information.

Current process analysis

This section is where you will use your analysis skills to describe how the client is handling the process now before you move in and optimize and automate it like a pro.

What are the steps that someone inside the company has to do each time to make this process work? What software do they have to use? Where do they get the information they need? What happens if something goes wrong? All these questions need to be answered in this section.

High level description

Here you should give an overview of the process. What is this process for? How often do they run it? When do they run it? Who runs it? What are the steps?

This overview description should be crystal clear and not too long to read.

Systems involved

Processes that are a good fit to be automated by automation often span across different systems. For example, one could be a web application, another a legacy system, or even just a spreadsheet.

List in this section the systems involved, don't forget to explain what they are used for and if the user needs to have special authorization roles or rights, because the robot will probably need to have them as well!

For our example, we will have Excel and the website listed here.

Process flow

One of the best ways to show the steps of a process is via a flowchart, a widely used convention when describing procedures and algorithms.

There is a variety of software to easily create flow charts: good options for example are Diagrams.net (free) or Lucidchart (free with paid option), or Microsoft Visio (paid).

PDD swag labs flowchart

Detailed steps

This section of the process definition document is the crucial one: here, you will break down the process into all its steps, and for each one, you will provide all the information needed.

Try to imagine that you are explaining this to someone that knows nothing about the process: after they have read your instructions, they should be able to complete the process on their own.

A good name for a step for example is in the format <operator> <action> <object of the action>. For example: "Employee adds product to shopping cart". This is not a hard rule though, just make sure that the name clearly and concisely describes the step.

In the description of each step, you are free to add anything that you think will help explain it better: for example, screenshots of the user interface, the schema of the data involved, etc.

Possible exceptions

So far, you have been describing an ideal case where the operator has all the data they need, all systems work perfectly together, and the end result is achieved.

This is not always the case: there are times where the process does not run that smoothly, or it cannot be completed for various reasons: we call these cases "Exceptions".

Exceptions can be of two types:

Logic exceptions: Logic exceptions happen when something is wrong with the information that is being processed. For example, if an order has incomplete data, the operation has to stop. Or maybe the business requires certain rules that the operator knows about: "do not sell more than ten pieces a day for that product". These need to be written down carefully because the robot will have to follow the same rules.
System exceptions: Software can have bugs, network connections can fail, passwords can no longer be valid: in all these cases, we say that a system exception has happened. Write down all these possible cases, explain what the operator sees, and if there are ways to get around them.