BPMN Examples

Business Rules and BPMN

Modeling Scenario

Let's say we want to model a process in BPMN and the process induces some business rules. We will use the example of creating a bill. In order to create the bill, a discount needs to be computed. The sum of the order and the customer type are the relevant criteria to compute the discount.

This is a very simple example which will show us where to apply BPMN and where not to.

The Solution as BPMN 2.0 Diagram

Explanation

During modeling, we focus on the process flow. In this example, the process has two steps. A discount is computed before the bill is created. The result is a very simple process.

It does not make sense to model the calculation of the discount itself in the BPMN model. For the rules decision tree, for every additional criteria, the cardinalities will grow exponentially.

Therefore, it makes sense to separate process and business rules.

The Wrong Way to Model It

Dependent Instances

Modeling Scenario

Let's say we want to model a process with concurring instances. We are using a simple example. If one credit check of a customer is running, we do not want another credit check for the same customer to be performed at the same time.

The reason could be that the total number of credit checks performed influences the result of the check.

Let's assume that we are running a credit check for a customer and we get a second request for the same customer at the same time.

What all solutions have in common is that every new instance needs to check for concurring instances on the data level before starting the actual credit check.

Solution with Signal Event

The signal event is the easiest and most compact way to model the interaction between different instances. The problem of the signal is that it functions as a broadcast and does not address any specific instance.

Solution with Message Event

This solution is a bit more complex, since you need to determine the recipient of the message. However, this is the correct way to solve the problem that occurs in the signal event solution.

Solution with Timer and Loop

In this example we do not need any communication between instances. The instance itself checks periodically if it can proceed to the credit check.

Four Eyes Principle

Modeling Scenario

We want to model the following situation using BPMN 2.0. For a request (e.g., a payment) two approvals of two different people are needed. A Process Engine should ensure that both approvals are fulfilled before the request is approved.

The Solution as BPMN 2.0 Diagram

Explanation

We use separate pools for the Process Engine, for the 1st Approver and for the 2nd Approver. This way, we can clearly define who is in control of which process.

The interaction between the user tasks in the engine and between the manual process of the approvers is modeled using message flows.

Variations

Approver as Collapsed Pools

Approver Determination with LDAP

Monthly Invoicing

Modeling Scenario

This example explains a very common struggle with structuring BPMN 2.0 diagrams. Let's say there is a lawyer who offers legal advice to his customers. The service works as follows: The customers can ask for legal advice whenever they need it.

This example illustrates a very common modeling scenario. It's not the steps of the processes that are difficult, it's the structure of the diagram.

The Solution as BPMN 2.0 Diagram

The most important aspect of the diagram is its structure.

The Provide Legal Advice process is performed many times per month. The Monthly Invoicing process is only performed once a month. Therefore, these two processes should be modeled as separate pools.

The Wrong Way to Model It

In this example, both processes are mixed into one. This is – at best – a very implicit way to model it.

Additional Information Required after User Task

Modeling Scenario

Let's assume we want to model the following scenario: we want to execute a user task which is performed by a user in a portal. After the user task is completed, additional information might be required.

Solution 1: Request information from another User

Solution 2: Request information from a technical service

Processing a Batch of Orders from a Marketplace

The Situation

We want to model the following scenario using BPMN 2.0: let's assume a company receives orders from different distribution channels. One of these channels is a marketplace. Within certain intervals of time, the orders from the marketplace are fetched as a batch.

The Solution as BPMN 2.0 Diagram

This example shows a very common modeling scenario. We sometimes call it a 1-to-n problem. One process instance (Import of Orders) results in many single process instances of another process (ERP System).

Reassigning User Tasks

Modeling Scenario

This example shows how to model the reassignment of user tasks in BPMN 2.0, a common requirement when the original assignee is unavailable.

Solution 1: Message boundary event and reassignment service

This makes sense if the engine calls a service to determine the new assignee.

Solution 2: Message boundary event and reassignment rules

This makes sense if the engine calls a rule engine to determine the new assignee.

Solution 3: Message boundary event and implicit reassignment

This makes sense if the engine determines the new assignee itself, e.g., by using an expression.

Two Step Escalation

Modeling Scenario

We will use the following example to illustrate how to model a two step escalation using BPMN 2.0. When we want a pizza, we order one. Sometimes the pizza delivery screws up and the delivery takes longer than 30 minutes.

Solution 1: Two Event-Based Gateways

Advantages of this solution

This solution very explicitly shows how the two step escalation is performed. Timers are modeled separately, followed by their corresponding escalation activities.

Disadvantages of this solution

Using two event-based gateways makes the model larger and leads to a duplication of the "Pizza received" message event.

Solution 2: Receive Task with timers attached

Solution 3: One Event-Based Gateway with a generic timer

Avoid Crossing Flows

Recommendation

This BPMN example is about creating a good layout of process models. The better the layout, the higher the degree of understanding.

Try to avoid crossing flows as much as possible. This will increase understanding of BPMN process models – for both experienced and inexperienced BPMN users.

Good Example of Handling Flows

Counter-example

Naming Conventions

Recommendation

Most important: every BPMN symbol should have a label.

Events should be labeled using object + past participle. Tasks should be labeled using object + verb. X-OR Gateways should be labeled with a question.

Good Example of Naming

The Generic Version

Counter Example

Symmetric Modeling

Recommendation

We have determined that symmetric structures increase understanding of BPMN process models – for both experienced and inexperienced BPMN users.

Good Example 1

Counter-example

Good Example 2

Counter-example 2

Use Equal Task Sizes

Recommendation

We recommend to always use equal task sizes. People tend to interpret task sizes although they do not have any semantics in the BPMN standard.

Good Example

Counter-example