Introduction to BPMN

Business Process Model and Notation (BPMN) is a graphical representation for specifying business processes in a business process model ^Wikipedia.

This is an opinionated introduction to some of the most common BPMN 2.0 symbols and their uses.

Sequence flow

BPMN sequence flow is made up of at least one start event, one end event, and any number of tasks (BPMN activities) in connection between them. sequence-flow.bpmn

Naming of elements

BPMN flow elements should be named using terms from the business domain of the process. Events are named to describe the business state of the process. Tasks (BPMN activities) are named using verbs to describe what actions to take in the process. sequence-flow-annotated.bpmn

Gateways and paths

BPMN gateways control which one of the available paths is taken at the time of execution. The exclusive gateway in the example allows only one path to be followed at a time (either to split or join the flow). gateways-and-paths.bpmn

Conditional flows

With exclusive gateways, you can direct the flow of the process based on the results from the completed tasks. This already allows you to implement complex workflows beyond the plain robot. sequence-flow-redux.bpmn

Concurrent tokens

BPMN token is a theoretical concept used to define the behavior of a process being performed. There can be any number of concurrent tokens in a single running process. For example, a parallel gateway creates a new token for each outgoing path. The process is only completed when all tokens have been consumed. concurrent-tokens.bpmn

Inclusive gateway

The inclusive gateway in the example allows multiple paths to be followed simultaneously, depending on the conditions defined. This means that one or more paths can be taken based on the evaluation of the conditions. gateways-inclusive-paths.bpmn

Multiple end events

Not all BPMN tokens need to reach the same end event for the process to complete. A BPMN process may have as many end events as it makes sense for the business process it describes. Not all end events need to be reached for the process to complete; the process completes when there are no more tokens alive. multiple-end-events.bpmn

Events at boundary

Attaching events to task boundaries is where BPMN superpowers really begin. In this example, a non-interrupting timer boundary event is used to send notification about test execution taking too much time. Non-interrupting events, as their name suggests, don’t interrupt the task they are connected to. Instead, they create a new token for the path they start (in the example, once or regularly as long as the task has not been completed). boundary-events.bpmn

Errors at boundary

There are two kind of errors in process automation:

• Application errors, which are caused by technical issues like network outages or programming errors, and can be fixed by retrying the failing part of the process once the technical issue has been resolved.

• Business errors, which are known exceptions in the process itself, and cannot be fixed by simply retrying, but must be expected and handled on the BPMN diagram level instead.

In this example, a business error is expected with a error boundary event (which is always interrupting), and it is used to route the process to an alternative end event. boundary-bpmn-error.bpmn

Embedded sub-process

Embedded sub-process looks like a process with its own start event and end event(s) within its host process. It is a powerful pattern to use for wrapping tasks that should share some boundary events. In this example, an interrupting boundary timer event is used to cancel the whole sub-process. embedded-subprocess.bpmn

Note

The example above could also be implemented using multiple boundary events on a task. However, this would change the behavior by allowing the task to handle multiple events simultaneously. Each boundary event could trigger different actions or paths, providing more flexibility and complexity in the process flow.

This approach is useful, however, when a task needs to respond to various conditions or events without interrupting the main process flow.

Event sub-process

Event sub-process can either interrupt the execution of the main process (with an interrupting start event) or run sub-processes in parallel to the main process (with a non-interrupting start event). The example does the latter with a non-interrupting start timer event. event-subprocess.bpmn

Externalized sub-process

Call activity is used to encapsulate and reference a reusable sub-process or another process, allowing for modular and maintainable process designs. In this example, it is used to hide the embedded sub-process details from the earlier examples. call-activity-process.bpmn

Basic task types

The examples above use only the so-called undefined task. This is useful for drafting and documenting processes, but not for actually implementing and automating them. There are many more concrete task types available.

Service task

Service task represents an automated task. All Robot Framework tests and tasks are modeled as service tasks.

Service task (custom)

Now that service task has become the core component in process automation, it has also become usual to customize its symbol to make it easier to recognize service tasks by some categorization. So, when you see a task element with a unique symbol, like the Robot Framework logo, it is safe to assume that it is a service task with just a custom symbol.

Call activity

Call activity calls a separately configured sub-process, which is defined outside of the main process (unlike an embedded sub-process). It allows abstraction of recurring parts of a process into reusable sub-processes, thereby reducing clutter.

User task

User task is a task meant to be completed by a human through a connected user interface. The most common way to implement a user task is to show the user a form.