Wonach suchen Sie?

BPMN Examples

Real-world BPMN 2.0 examples and answers to common questions.

Online Modeler

Our modeler is an online and desktop tool for designing, discussing and sharing BPMN diagrams with your team.

Overview

We have taught BPMN to thousands of people and we apply the notation in our daily project work since 2007. Below you can find lots of BPMN examples of common modeling problems. Regardless of your specific project or your industry, there are a lot of common questions about using BPMN. In our experience, most of the BPMN examples below are useful to any BPMN user.

We joined the OMG in 2009 as an influencing member. Since then, we have been participating in the development of BPMN 2.0.

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

Rule Engine Create Bill Bill requested Compute discount Create bill Bill created

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 (see the example below). For the rules decision tree, for every additional criteria, the cardinalities will grow exponentially. That is not what we want in a BPMN model.

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

The Wrong Way to Model It

Create Bill Compute 2% discount add an extra 1% discount customer type? Bill requested Sum of order? customer type? Create bill Bill created Compute 3% discount Compute 4% discount customer type? add an extra 1% discount add an extra 1% discount 1000 – 1500 500 – 999 >2000 < 500 Type A Type A Type A ordinary ordinary ordinary

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

Creditworthiness Check Check requested check for running instances (of same customer) running instances of same customer? perform credit check credit check performed credit check performed Engine Database no yes

Explanation

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. So, strictly speaking, the customer is ignored and all waiting instances catch it.

Solution with Message Event

Creditworthiness Check Check requested check for running instances (of same customer) running instances of same customer? perform credit check credit check performed waiting instances of same customer? check for waiting instances (of same customer) running instance finished inform waiting instance Engine Database Engine Database no no yes yes

Explanation

This solution is a bit more complex, since you need to determine the recipient (a single instance) of the message. That induces a second data request before the end of the instance. However, this is the correct way to solve the problem that occurs in the signal event solution.

Solution with Timer and Loop

Creditworthiness Check Check requested check for running instances (of same customer) running instances of same customer? perform credit check wait some time credit check performed Engine Database no yes

Explanation

In this example we do not need any communication between instances. The instance itself checks periodicity if it can proceed to the credit check. The downside is that this might cause delays and overhead due to the loop.

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 manual steps that are performed by the two approvers should also be modeled in the BPMN diagram. The approval decision is performed using a portal with a Tasklist.

The Use Cases

The use cases for this pattern are numerous. Here are some examples:

  • Payment Approval
  • Invoice Approval
  • Contract Approval

The Solution as BPMN 2.0 Diagram

1st Approver Approval requested evaluate request document and submit decision task completed Process Engine Approval requested decide on approval (1st stage) approved? request rejected (1st stage) decide on approval (2nd stage) approved? request rejected (2nd stage) request approved 2nd Approver Approval requested evaluate request document and submit decision task completed no yes yes no

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.

In the engine pool, user tasks are used. These user tasks correspond to the tasks which are shown in the Tasklist of the 1st and the 2nd approver.

The interaction between the user tasks in the engine and between the manual process of the approvers is modeled using message flows. These message flows encapsulate the manual steps which the approver needs to perform in order to complete the user task.

The Tasklist itself is not modeled, in order to reduce complexity.

Variations

Approver as Collapsed Pools

1st Approver 2nd Approver Process Engine Approval requested decide on approval (1st stage) approved? request rejected (1st stage) decide on approval (2nd stage) approved? request rejected (2nd stage) request approved no yes yes no

Approver Determination with LDAP

1st Approver Approval requested evaluate request document and submit decision task completed LDAP Process Engine Approval requested decide on approval (1st stage) approved? request rejected (1st stage) decide on approval (2nd stage) approved? request rejected (2nd stage) request approved determine 1st and 2nd approver 2nd Approver Approval requested evaluate request document and submit decision task completed no yes yes no

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. The lawyer provides the requested advice and puts the billable hours on the customer’s time sheet. When the month is over, the lawyer’s accountant determines the billable hours based on the time sheet and creates the invoice.

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

Lawyer Provide Legal Advice Legal Advice requested provide legal advice register time Request handled Customer Time Sheet Customer Accounting Monthly Invoicing 1st day of month determine billable hours create and send invoice money received Invoice settled 14 days send reminder just one instance per month many instances per month

Explanation

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.

Of course these two pools are not completely independent from each other. Why? They work on the same data – the customer’s time sheet. Our ability to model such a data-related connection is very limited in BPMN. This is due to the fact that BPMN is focused on control flow rather than on data flow.

However, we can use the data store element to model this connection on the data level.

The Wrong Way to Model It

Lawyer Provide Legal Advice Legal Advice requested provide legal advice register time 1st of next month determine billable hours create and send invoice money received Invoice settled 14 days send reminder Customer

Explanation why this is wrong

In this example, both processes are mixed into one. This is – at best – a very implicit way to model it. It would mean that for every provided legal advice an invoice is sent once the month is over. This way of modeling is wrong in most cases.

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. If that is the case, the process engine sends an information request either to another user (solution 1) or to a technical service (solution 2).

Solution 1: Request information from another User

User in Portal User in Portal Process Engine some task for the user additional information required? request information (from user) no yes

Solution 2: Request information from a technical service

User in Portal Some Technical Service Process Engine some task for the user additional information required? send information request (technic al) information received no yes

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. Every order in this batch needs to be validated before being imported into the ERP System.

The Solution as BPMN 2.0 Diagram

ERP System Some Marketplace Import Orders from Marketplace to ERP Every 10 minutes Collect all orders from marketplace Process Order New single order Check order data data correct? Import order to ERP system Single order processed Order data incorrect All orders processed for each single order no yes

Explanation

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). Typical constructs are multi instance or loops that start other processes using messages (message flows).

Reassigning User Tasks

Modeling Scenario

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). Typical constructs are multi instance or loops that start other processes using messages (message flows).

Solution 1: Message boundary event and reassignment service

User in Portal Process Engine determine assignee some user task assignee unavailable

Note

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

Solution 2: Message boundary event and reassignment rules

User in Portal Process Engine determine assignee some user task assignee unavailable

Note

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

Solution 3: Message boundary event and implicit reassignment

User in Portal Process Engine some user task assignee unavailable

Note

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. Then we complain to the delivery service. After that, we give them another 20 minutes to deliver the pizza. If they do not make it in time, we give up and cancel our order.

Solution 1: Two Event-Based Gateways

Pizza wanted Order Pizza Pizza received Eat Pizza Pizza eaten 30 minutes Complain to Delivery Service Pizza received 20 minutes Cancel Order Order cancelled

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

The event-based gateway is not an intuitive BPMN symbol of the BPMN standard, experience is required.

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

Pizza wanted Order Pizza Eat Pizza Pizza eaten Complain to Delivery Service Cancel Order Order cancelled Wait for Pizza Order complained 50 minutes 30 minutes

Advantages of this solution

This model is smaller than the first solution and probably the way most developers would solve the problem on the engine. Since we use a non-interrupting attached timer event, this solution is more flexible when it comes to multiple complaints (e.g., we want to complain every 5 minutes until 50 minutes are over).

Disadvantages of this solution

The receive task is usually not intuitive for the “business guys”, who would rather use message receive events for that kind of wait state.

The way that the interrupting and non-interrupting timer collaborate requires profound understanding of attached events.

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