Beginners Guide to

Business Process
Modeling and Notation
(BPMN)
Try Smartsheet for Free

Although many big organizations still use the written word to describe their processes and
requirements, a significant amount of evidence suggests that pictures are a better way to
communicate. This is where modeling languages come in. Modeling languages allow
companies to show their processes pictorially to minimize error and miscommunication.
They can also be used to delineate responsibilities, find areas for improvement, and plan for
future changes.

In this article, we look at business process modeling and notation (BPMN) as a standard of
modeling languages for enterprises. We’ll discuss what it is, what it was, and how it should
be used. We’ll review BPMN elements and extended elements in detail, as well as provide
guidelines for modeling and tips for using the notation. We present examples of BPMN
models, and finally, we’ll offer a method for choosing a BPMN tool.

 What Is Modeling Notation and BPMN? An Overview

 When to Use BPMN
 BPMN Goals
 BPMN Diagram Perspectives
 Target Audience for Business Process Modeling Notation
 BPMN Elements
 Extended BPMN Modeling Elements
 BPMN Critique
 Guidelines of Process Modeling
 How to Select a BPMN Modeling Tool
 How to Implement a BPMN Process Map
 Quintessential Tips for Working with Business Process Modeling Notification
 Other Business Process Modeling Languages
 Build Powerful, Automated Business Processes and Workflows with Smartsheet

What Is Modeling Notation and BPMN? An

Overview
Process modeling notation is a language that’s readable to humans and that describes the
structure and elements of a business sequence. The vocabulary is defined, and the
language is organized such that we understand how it should flow and how the information
is presented. As a data science, process modeling notation includes about 40 different
elements, delineated with rules about their use.
This language tells stories about our work. By creating a model similar to a flowchart with
this language, a business can capture, analyze, understand, automate, and even optimize
their processes. As with any language, it’s important to learn the terms and rules of
grammar. Since the 1960s, countless notations and their varying structures have come and
gone. When it comes to a modeling notation, experts recommend that you choose a
standard that is based upon your purpose, that it is supported by a wide number of tools,
and that comes with training and references.

Business Process Model and Notation (BPMN) is a standardized graphical notation that is
used globally for business process modeling. It is open source, which means that the
original code is available for anyone to change and use. The specification defines its
symbols and shapes precisely.

BPMN starts and ends with the business process flow diagram. This is a technical map of
an organization’s flow and practices, presented in a standardized language, and available
for users to improve, share, and follow.

The Object Management Group (OMG), a nonprofit technology standards consortium,

governs and maintains BPMN. OMG offers several certification programs, including the
OCEB Certification (OMG Certified Expert in BPMTM) for BPMN. The field of business
process management (BPM) approves of standardization and often uses software (BPMS)
that includes the BPMN language. Some are low-code platforms, meaning that the business
can configure its BPMS to work with its incumbent software and needs.

The BPMN language is not owned by a commercial enterprise, though Trisotech is a

commercial software and consulting company that helped develop BPMN by building on its
standards internationally. It has also been involved in developing and setting BPM
standards, XPDL, BPSim, and CMMN, and is considered a leader in BPMN consultation.

At its core, BPMN is intuitive. Even when staff members do not understand the exact
symbols, they can figure out the meaning of the workflow. However, for more advanced
users, the nuances are apparent. For example, in the simple process below, Lane 1 starts a
task. This could be your company, which is the pool. Your department is Lane 1, which
starts the process and completes the first task. The work is then sent to another department
(in Lane 2), which sends it back for Task 3 and completion. This seems more complex with
the standardized language, but if you add names, it is very clear. You can model this
simplicity throughout your processes, even those that appear very complex.

A simple BPMN process map

OCEB 2 Program
The OCEB 2 Program has five examinations, each offering a certification. After the
Fundamental level, there is a track for business and another for technical. In the BPM world,
these certifications assure employers that you understand not just the principles, but also
the practice of BPM. The OCEB 2 Certification was designed by 25 BPM professionals from
the commercial industry, with the intent of providing this assurance to their peers and
prospective BPM employers. The certification gives BPM practitioners an edge over their
uncertified competitors.

When to Use BPMN

Different users of BPMN describe it as simultaneously complex, simple, prohibitive, and
helpful. There are certainly times when you will prefer to use this standardized language.
Three reasons you would want to use BPMN versus another notation include:

 Its use is tied to organizational objectives. In this scenario, your business would
require a specific modeling notation language in order to stay consistent, especially if
they have international business interests. Out of necessity, this modeling is generally
more formal than most.
 You commonly use the same handful of elements in a specific concept. In this
scenario, you are able to draw selectively from BPMN as needed, and there is less
concern about other users misunderstanding.
 You want to show your breadth of BPM knowledge. Nothing says you are a BPM
expert like understanding the modeling language designed specifically for it. When
you apply for positions that require BPM expertise, this knowledge and experience
could set you apart.

OMG merged with the Business Process Management Initiative (BPMI), the inventors of
BPMN, in 2005. Since its inception, five releases of BPMN have followed. BPMN 2.0 arrived
in early 2011. The five versions and their dates of release are below. Each version is linked
to its official specifications.

 BPMN 1.0, released May 3, 2004

 BPMN 1.1, released January 17, 2008
 BPMN 1.2, released January 3, 2009
 BPMN 2.0, released January 3, 2011
 BPMN 2.0.2, released January 3, 2014

BPMN was originally a modeling notation that was meant to give all stakeholders, from high-
level decision makers to technical staff, a standardized language for diagrams. But with the
release of version 2.0, BPMN became about models and notation. The difference is that
instead of standardized models alone, BPMN offers a standardized XML (Extensible Markup
Language) schema that can map between software tools. At this time, more than 80 tools
support BPMN.

OMG originally developed the Business Process Definition Metamodel (BPDM) as a bridge
between BPMN and software. BPDM describes the rules, constraints, and theories of BPMN
so that software programs can map and use it with an XML syntax (such as the Business
Process Execution Language, or BPEL). The originators thought users should be able to
move process models from one modeling tool to another without losing information.
According to OMG, “By providing a common, syntax-independent vocabulary for business
process concepts, BPDM standardizes the way BPMN diagrams are stored and
exchanged.” However, according to experts, the advent of BPMN 2.0 negates the need for
BPDM. Further, experts say that BPEL does not fully support BPMN.
BPMN 2.0 also improves the following:

 Semantics: The execution semantics (meanings) for all BPMN elements were
formalized.
 Notation: New diagram types were added with new contexts for use. These include
choreography and conversation diagrams. Choreography diagrams center on the flow
of messages and between-process interactions. These diagrams chiefly focus on the
interaction between the pools. There is no central control, responsible entity, or
observer. Conversation diagrams focus on conversations between the participants,
showing a bird’s-eye view of the information exchange between participants. BPMN
2.0 also made improvements to events, adding non-interrupting events and event
subprocesses. We discuss the event improvements in the “Extended BPMN Modeling
Elements” section of this guide. With sub-processes, BPMN 2.0 added more than 50
new elements. Elements are the symbols that represent different parts of the process.
 Technical: The formal meta-model was defined.

Example of choreography diagram. The choreography diagram in the center represents the
communication between the pools.
Example of conversation diagram. Conversations diagrams show a different view and
incorporate two new elements: the hexagon and the double line.

According to some experts, not everything in BPMN 1.0 has a partner in BPMN 2.0.
However, software packages are available that provide migration pathways to update older
models.

OMG states that there will not be another version of BPMN for at least two to three more
years. Since many users want a stable long-term platform, OMG is not in a hurry to get to
BPMN 3.0. In 2014, OMG did release a complement to BPMN called the Decision Model
and Notation (DMN), which provides a separation in the decision and the process. DMN was
designed to work to connect with BPMN as a schema model in XML format via the identified
processes and tasks, as well as through the decision knowledge base data type. In other
words, BPMN shows the processes, while DMN models show how decisions are made in
the processes.

BPMN Goals
BPMN’s main goal is to be a notation that all users can understand. This includes not only
the businesspeople who manage all of the processes, but the business analysts and the
technical developers. Other goals of BPMN include:

 Provide a consistent structure.

 Be highly readable throughout all levels of the process.
 Ensure that the model is complete without any additional documentation required.
 Be able to be shared with IT as an executable process.

Your BPMN diagram should represent not only business process activities, but can and
should show the following:

 Any information that is exchanged during process implementation.

 Control checkpoints that show the sequence of data exchange and activity
implementation.
 Personnel roles and any needed additional personnel.
 What information systems support the process.
  How the process in regulated in the business rules and legal framework.
 The implementation.

BPMN Diagram Perspectives

Many organizations strive for interoperability, where different software applications and IT
systems are able to communicate, exchange data, and use the information and knowledge
from the exchanged data. You can consider interoperability from three perspectives: private
business processes, public business processes, and collaboration business processes. For
IT, these perspectives are important for the ability to exchange data.

Private business processes detail:

 Internal activities
 Departments responsible for each task
 Documentation
 Rules that regulate the processes
 Information systems

Public business processes:

 Concentrate on the interaction between internal processes and those of other

organizations
 Do not review organizational structure, information systems, or rules

Collaboration business processes:

 Show all interactions for every organization in the process (two or more businesses)
 Do not provide internal processes for any organization
 Help identify the software that supports the processes
 Contain two or more pools

This makes sense in BPMN, because part of the purpose of BPMN 2.0 is to exchange
BPMN models between different software systems. There are noted limitations on this
interchange; these are intentional on the part of the designers of BPMN 2.0 because they
wanted to ensure maximum flexibility. Visually, these include colors of shapes and text,
shape decorations such as shadows, gradients, backgrounds, text wrapping, and thickness
and style of lines. Semantically, these include proprietary extensions such as the script of a
script task, user task implementation, and global user task implementation.

BPMN Constraints

For all of BPMN’s capabilities, it is specifically constrained to business processes. Some

organizations and analysts assume that BPMN is a magic bullet for all of their process
modeling needs. However, the following processes are not meant to be supported by
BPMN:

 Organizational structures and resources

 Functional breakdowns
 Data and information models
 Strategy
 Business rules

These types of processes can be addressed in other UML models or additional

documentation. It must be noted that BPMN models are not data flow diagrams (DFDs),
which show the flow specifically of data information from one place to another. These
diagrams provide only one view of a process through the data.

Target Audience for Business Process Modeling

Notation
BPMN was designed so that all users can understand it: businesspeople, business analysts,
and IT staff. Although the BPMN originators had these groups in mind during development,
they were also concerned with how they could link BPMN to other OMG standards. Further,
although the standard supports all of these professionals, not all professionals design to the
same level.

Bruce Silver discusses three levels of BPMN users in the trainings that he conducts. Level 1
is your typical user who employs only a handful of symbols. Their diagrams are simple and
conform to a very traditional standard. Some journals estimate that almost 90 percent of
users are at this level of design. (This figure is referenced by many blogs and periodicals,
but there is no specific study that supports it.) Level 2 users provide the layer that IT
professionals can then add to. It is essentially a more advanced business process layout
using less common

BPMN Elements
BPMN keeps elements of a business process model to a minimum so that the look and feel
of the diagram stays as consistent as possible. You can always add more detail after the
basic categories are complete.

There are two types of elements: descriptive and analytic. Within this framework, you’ll find
over 40 different elements, each with rules about when they can and cannot be used.
Business analysts developed descriptive elements to model processes as documentation,
and technical staff developed analytic elements to model executable processes within the
software.

The five basic categories of elements are:

1. Flow Objects. These define the behavior of business processes.

 Events: What happens during a process. There are three main types: Start,
Intermediate, and End. An event is also what happens during a process. For
example, an event could be that “a message is sent,” “an error occurred,” or “cycle is
completed.”
 Activities: Work performed in a process; also known as tasks.
 Gateways: These determine the sequence flow path in a process. Gateways have
internal markers that give additional detail to show how the flow is controlled. These
are decision points in a process. For example, if a condition is true, then processing
continues one way; if false, then another.

2. Data: These elements call out information about the activities. Data is either provided or
stored for the activity.

 Data objects
 Data inputs
 Data outputs
 Data stores, where processes can either read or write information. A data store
continues beyond the life of the process.

3. Connecting Objects: These connect the flow objects to each other or to other
information.

 Sequence flows: This element shows the order in which activities are performed.
 Message flows: This displays the messages and the order of flow between
participants.
 Associations: This element is used to link information and artifacts (see below).
 Data associations: These have an arrowhead to indicate direction of flow in an
association.

4. Swimlanes: In BPMN, a swimlane is an element that shows where the responsibility for
the process resides, and a pool represents the participant. Lanes break apart the pool as a
partition of responsibility, showing the location of activities. Lanes can also delineate phases
(first phase, second phase, etc.). In other words, a pool is a container for a single process,
and a lane classifies the activity within it.

Lanes do not have semantics in BPMN; they are merely a partitioning concept. You can
arrange swimlanes either vertically or horizontally. Lanes are optional and may be nested.
Some issues with swimlanes:

 Flow elements are connected differently depending on whether they are in a pool or
between pools.
 Only message flows can be used when communicating between pools. Message
flows designate the exchange of messages.
 A pool cannot contain more than one process.
 Sequence flows should not be used between pools. Lanes are more appropriate
where sequence flows are necessary, not pools.

5. Artifacts: These are used to give extra detail about the process. The two standardized
artifacts are:

 Groups: This is a hatched box around a group of elements to designate visually that
they are related. This does not affect sequence flows.
  Text Annotations: Extra text, attached with an association, that gives additional
information. Also known as a comment.

6. Message: This element is shown in the tables in the specification guide for BPMN, but
not put into a specific category. It is used in extended notation as well. A message
represents communication between participants.
The five basic categories of BPMN elements.

Extended BPMN Modeling Elements

Extended modeling elements take the basic elements, add notation, and change their
meaning while still showing consistency. The following sections are a foray into extended
elements. The elements shown are not meant to be exhaustive, but provide the most
commonly used elements in BPMN.

An example of an extended element is the use of a Start Event. A message element is then
added, and the meaning changes from plain “Start” to a “Start triggered by a message.” The
extended modeling element in this scenario allows users to specify how the event begins,
not simply that it has begun, adding to the detail in a process.

Events Extended

We know there are three type of events: start, intermediate, and end. These events can also
be broken down into catching events, throwing events, and interrupting or non-interrupting
events. A trigger defines catching events. Once the trigger is activated, the event starts.
Throwing events are assumed by BPMN to trigger themselves. They do not react to triggers;
instead, the process triggers them. Whether an event is interrupting or non-interrupting is
related to the action. When an interrupting event is fired, the action is blocked. When a non-
interrupting event is fired, the action continues.
Extended Event Sub-Processes

Activity Tasks, Sub-Processes, Transactions, and Call Activities Extended

You can add to tasks as well, with extra notation to show more specificity. The following
image shows the notation and the meaning of each.

 Receive waits for a message from an external participant.

 Script is a task executed by the engine.
 Manual is a task the operates without the aid of engines or applications.
 Receive (Instantiated) is a task that is designed to wait for a message to arrive from
an external participant. It then instantiates a process.
 Service is a task that uses a web service or automated application.
 User is a human task scheduled through a manager.
 Send is a task that is designed to send a message to an external participant.
 Business Rule is a task that confirms with the business rules engine the input prior to
executing.
Three types of markers are specified for a task as well. These include loop, multiple
instance, and compensation.

 Loop will continue as long as the condition is true; a numeric cap may be specified.
 Multiple instance may execute in parallel or sequentially. An expression or a data-
driven setup can be used to determine the number of instances.
 Compensation tasks specify some type of recompense or payment, either into or out
of the process.

Loop tasks, sequential multiple instances tasks, and compensation tasks, respectively.

Sub-processes show lower levels or more detailed levels in a process event task. A
collapsed sub-process is shown below:

Additionally, you can combine four types of markers with the sub-process marker. These
include loop, multi-instance, ad-hoc, and compensation.

Source: OMG

Transaction Sub-Process
A transaction sub-process is embedded. You can use it to group multiple activities and show
that they either fail or succeed collectively. These groupings of processes are surrounded by
a double border to show they are a transaction.

In the above example, the flow moves to a Cancel End Event in the case of an error due to
unavailable bookings. This activates the process rollback, and any completed reservation
activity will be undone. The tasks in this example are undone in the reverse order that they
were completed.

Gateways Extended

Notation may be added to gateways to represent different kind of control behavior, such as
making decisions, branching, merging, forking, and joining. The types of possible gateways
are exclusive, event-based, inclusive, complex, and parallel.

 Exclusive gateways are the main type. They may have the X in the middle, or they
may be empty. They model alternative paths and are where the diversion takes place.
 Event-based gateways are used to model the alternative paths, but are based on
events that occur, not the expression of flow.
  Inclusive gateways can be used to model alternative and parallel paths. They
evaluate all condition expressions and take paths with a positive result.
 Complex gateways model complex synchronization behavior.
 Parallel gateways create and join parallel flows. They check no conditions.

Data Objects Extended

Data objects are available in processes and sub-processes. Aside from the main type of
data object, you can add notation to indicate data input, data output, collection data item,
collection data input, and collection data output. Data inputs and outputs relate to the entire
process. Collection data relate to the actual collection of some type of information during the
process.

From left to right: Data input, data output, data object collection, data input collection, and
data output collection.

Connecting Objects Extended

The addition of extra notation to connecting objects can extend their usage in BPMN. These
include conditional flows, default flows, exception flows, and compensation associations.

 Conditional flows are used in merging and branching in place of a gateway. A

conditional expression is defined at its origin.
 Default flows are only selected if no other sequence flows available. Conditions on a
default sequence flow are always ignored. There may be only one default flow per
object.
 Exception flows occur outside of the normal flow of the process and are based on an
intermediate event on the boundary.
 Compensation associations are used when an activity is canceled, and the process
must be set to its original state.

Conditional flows and default flows.

Exception flows and compensation flows.

BPMN Critique
Critics have written widely about BPMN and why it is not appropriate for widespread use.
The majority of the criticism centers on BPMN’s complexity. With more than 100 unique
elements (resulting from the five main elements and their additional notation), it is too much
to learn, too easy to make errors, and too granular for business processes alone, according
to critics. Further, doing BPMN for the sake of doing BPMN causes more harm than good.

Other risks of BPMN include:

 Mistakes in the Modeling Elements: This would decrease the clarity of process
flows, rather than increase the communication.
 Increased Complexity in Modeling: With more time required for analysis, the value
of the product decreases.
 Lack of Stakeholder Understanding: If stakeholders need everything explained, it
could introduce errors and incorrect information.

Bruce Silver, who helped draft BPMN 2.0, says, “Business analysts should learn the
semantics and rules, and that for most effective use the method and style of BPMN should
also be learned.” Most professionals and organizations stick to a handful of symbols, so
there is not much to learn. This in fact makes the notation simple. Diagrams can be
extended for more granularities as needed, such as with an IT implementation. Further,
BPMN is designed to model both human-centric and IT processes with equal accuracy. It
also has the power and precision to display a clear vision of how your business works,
saves time by showing unnecessary tasks, and reduces your employees’ rates of
overlooked, forgotten, or poorly executed work.

BPMN diagrams have certain capabilities that other modeling languages do not. According
to Silver, “Restricting BPMN to the part that is familiar from traditional process mapping is to
miss its essence, which is the expressiveness required to describe not only the process’s
normal or ‘happy path,’ but the various exception paths as well, and to do so with the
semantic precision needed by IT to translate any proposed improvement into a working
implementation.”

Essentially, Silver is saying that while it is well and good to model the few simple elements,
the real value of BPMN lies in its capacity for the unusual circumstances (the exception
paths) and to have those translated for automation. (Note: A happy path is the default
scenario that features no exceptions or error conditions — the sequence of events where
everything goes as expected.)

Even with the criticisms leveled at BPMN, it is still one of the most widespread and desired
standards for process modeling available today. According to “The State of Business
Process Management 2016 Report”from BPTrends, 64 percent of businesses surveyed are
interested in adopting BPMN.
Guidelines of Process Modeling
Process modeling guidelines are the same for any language or notation. In a 2009 paper on
process modeling, authors Mendling, Reijers, and van der Aalst explain the main guidelines
of modeling, regardless of the language used. They outline guidelines that may be
considered best practices:

1. Use as few elements as possible in the model. This aids readability and decreases
errors.
2. Minimize the routing paths per element. BPMN regulates routing paths via gateways.
3. Use one start event and one end event. BPMN requires this, and depending on the
software it does not allow more than one. BPMN does give intermediate events
where required.
4. Model as structured as possible. This means that the diagrams are balanced. In
BPMN, gateways should not be used to join and split at the same time; they should
be balanced and joined equivalently. Further, the same type of gateway should be
used to split and join the flow.
5. Avoid or routing elements. This means that elements in models should not be an
either/or question, but modeled such that the decision is an and or an xor.
An xor gives mutually exclusive answers. In BPMN, gateways are not capable of
being and.
6. Use verb-object activity labels in your naming convention. This decreases ambiguity.
7. Draw your models left to right (not top to bottom) unless the bulk of your stakeholders
write ideographic languages (such as Japanese, Chinese, etc.) for easier
understanding.
8. Decompose the model if it has more than 50 elements. That is, break a system into
its component subsystems, processes, and subprocesses. This is related to guideline
number one, in that having the least amount of elements keeps the errors low. BPMN
has sub-processes that can decompose a model.

How to Select a BPMN Modeling Tool

To take full advantage of the BPMN modeling language, use a tool. Although you can draw
BPMN with a pencil and paper, doing so does not take advantage of the majority of its
benefits. Software programs that specialize in BPMN allow users to model faster and easier,
and it enforces the majority of the BPMN rules automatically. Software tools also decrease
errors in the diagram, allow for easier reading on the human eye, and give the all-important
capacity to capture the associated XML.

What are the recommended criteria in choosing a BPMN tool? At last count
by BPMtips.com, there were anywhere from 70-100 tools that could fully support BPMN
modeling. These include free, open source, and proprietary tools, as well as tools whose
sole function is not BPMN, but support it anyway. To further complicate the selection
process, a number of plugins to existing programs support BPMN modeling. The choice you
make is critical because much time and money will be invested in not only learning BPMN,
but in the production of the models.

Experts agree that if your business needs the standardization of BPMN, then the tool should
first be able to claim BPMN compliance. For BPMN 2.0, compliance is defined within the
ISO/IEC 19510:2013 standard. This ISO standard represents the best practices in business
modeling. If the language is meant to be consistent in its meaning, it must first be
standardized. In this, the tool must have four types of conformance:
 1. Process Modeling Conformance supports the elements and attributes of three
subclasses: the descriptive, analytical, and common executable. The descriptive and
analytical subclasses provide the information necessary to visually represent the
diagrams. The common executable is the description of the data for the XML and
meta-model.
2. Process Execution Conformance tools must fully support the import of process
diagrams. This is the support and interpretation of the meta-model via the semantics
and activity lifecycle.
3. BPEL Process Execution Conformance supports full mapping, from BPMN models to
BPEL.
4. Choreography Modeling Conformance tools provide elements, appearance,
semantics, and interchange, as well as BPMN choreography types.

Aside from actual BPMN conformance, one method to choosing a modeling tool is as
follows:

1. Define your business objectives and requirements. Know ahead of time what
functional and nonfunctional requirements your business will have for BPMN.
2. Define the selection criteria and the weight of each. Do your users need syntax
checks? Do they need pop-up menus? Do they need help in documentation? Develop
a chart that delineates your business’s required criteria, so you can pick a program
that meets your needs.
3. Identify some candidate tools. With as many tools available to date, it is impossible to
test-drive all of them. Once you delineate and weight your selection criteria, some of
the potential tools will not be feasible. From there, if demos are available, order them.
Evaluate how easy it is to install, identify any operability problems, and explore the
support in the BPMN tool.
4. Test-drive one model. Once you discover the best candidates, use a consistent
model that represents your company to test across the remaining applications.
5. Select your winner. Once you have multiple examples of the same model, you will
have notes on each program, how easy the model was to develop, and the end look
and feel. This should lead to your choice of BPMN tool.

How to Implement a BPMN Process Map

It is clear that BPMN is a relatively simple, straightforward language that professionals use
to standardize their process maps. If you have existing process maps, you could start by
standardizing them with BPMN symbology. If you haven’t mapped processes before, start
by creating the maps:
Download Mapping Processes Checklist
 Download Optimizing a Process Checklist

Quintessential Tips for Working with Business

Process Modeling Notification
There is little doubt that learning BPMN is complicated, but it appears to be a worthwhile
venture. Some BPMN experts have formal education, and some do not. Reading the current
specification manual from OMG is not considered the best way to learn to model BPMN.
Most, if not all, experts agree that learning through doing is best, putting the elements into
understandable context.

1. Model with a top-down approach. According to Stephen White in an interview on the

Leonardo Blog, “The top-down approach will ensure that the depth of modeling is
consistent throughout the effort of process modeling in your organization. I'm not
saying that every single process model needs to be the same amount of granularity. It
depends on the purpose.”
2. Every BPMN symbol should have a label.
1. Events should be labeled object + past participle. For example, “Process
started.”
1. Start events should have how the process is activated.
2. End events should have the process “end state.”
2. The pool should always be labeled with the process name and role (for lanes).
3. Tasks should be labeled as verb + object. For example, “Eat lunch.”
4. Gateways should be labeled with a question. For example, “Packaging
complete?”
5. Outgoing sequence flows should be labeled with answers to the gateway
questions. For example, “yes” or “no.”
3. Avoid crossing flows as much as possible. A good process layout with few crossing
lines is easier to read.
4. Symmetric structures are easier for the human brain to understand.
5. Draw equal task sizes. However, the size of the task element does not indicate the
size of the task in BPMN.
6. Show exception handling explicitly.
7. Use message flows consistently. Attach the message flows to the boundary of the
process pool at all levels of the diagram to add to your business context.
8. Consider using sub-processes to define scope. Sub-processes can be wrapped
around part of your sequence when exceptions occur without penalty.
9. Limit the number of concepts in the model. Since most BPMN users are describing
business processes, users should keep it simple and only use the required elements
for maximum readability.
10. Set standards for your organization. Clear, regularly used conventions, such as
elements, naming, methodology, and layout should be developed per business so
that there is additional consistency for stakeholders.
11. Consider using a legend that explains the symbols for stakeholders who are not often
exposed to BPMN.
12. Try not to simply send diagrams out to stakeholders, but take the time to explain the
processes to those not trained in BPMN.
13. Consider making two models of the same process if you have a large number of
stakeholders without BPMN experience: one model for business users (with less
elements), and one executable model.

BPMN Diagram Samples

The following models are from OMG, and they represent most of the elements described in
this guide. This should give you an understanding of how a BPMN diagram looks.

The Pizza Collaboration

Shipment process of a hardware retailer

Other Business Process Modeling Languages

No discussion of BPMN would be complete without reviewing other modeling languages,
such as BPEL, YAWL, and UML. These languages have been used in the evolution of
BPMN, to make it more applicable and garner wider use in the industry.

Business Process Execution Language (BPEL) and BPMN

BPEL (officially known as web services - business process execution language, WS-BPEL)
is an XML-based orchestration language that allows companies to seamlessly work together
by using web services to share data. It was created to standardize how processes are
executed. Generally, it is meant for completely automated processes, especially when
companies want to turn processes into XML for automation, even robotic process
automation (RPA).

BPEL is based on web services in that each of the business processes involved are
considered to be a web service. BPEL specifies the order in which web services should be
invoked. An orchestration language identifies the executable process of message
exchanges with other systems. BPEL supports two types of business processes: executable
and abstract processes. BPEL is mainly meant to be employed by IT users, primarily
because there is no graphical notation associated with it. BPEL is not meant to be accessed
by business analysts or end users.

BPEL was often used in conjunction with earlier versions of BPMN. Users wrote BPMN
notation, and BPEL was the execution language. Although there was and currently is a very
high degree of correlation between BPMN and BPEL, there is no perfect system for one-to-
one mapping between them. Some business processes may map in a way that is not
executable. With the release of BPMN 2.0, BPEL was no longer necessary as the core XML
language. BPMN 2.0 came with its own XML specification language.

Current trends in the industry suggest that more businesses are leaning toward using BPMN
2.0, and BPEL adoption has decreased considerably since 2007. According to “The State of
Business Process Management 2016 Report,” only 8 percent of businesses are interested
in adopting BPEL.

There are arguments within the industry that revolve around when to use BPEL vs. BPMN,
especially since there is overlap between the two, and many problems could be solved
using either BPMN or BPEL. Most large enterprises do not consider using only BPMN or
BPEL; instead, they use both, depending on the scenario. Experts recommend that if your
organization needs both, keep the BPEL worker processes in separate composites from the
BPMN business processes. The following is a chart, culled from countless sources around
the web, that details different scenarios where either BPMN or BPEL are recommended.
Yet Another Modeling Language (YAWL)

YAWL (yet another modeling language) may be considered an alternative language to

BPEL. YAWL is based on Petri nets, which are part of a mathematical modeling and
reasoning language. It is also open source, which means that the original source code is
available to anyone to change and use. YAWL is considered easier in communicating to
stakeholders than BPEL because of the intuitive user interface. YAWL and BPMN have
some concepts in common — namely, tasks, gateways (as a decorator in YAWL), and flow.
Unified Modeling Language (UML)

Unified Modeling Language (UML) is a general-purpose modeling language also managed

by OMG and published by the International Organization for Standardization (ISO) as an
approved language standard. UML is similar to BPMN in that it is an open source modeling
language. Whereas the whole of BPMN is devoted to business process modeling, only
UML’s activity diagram is suitable for business process modeling. Overall, UML is object-
oriented, while BPMN is process-oriented.

Build Powerful, Automated Business Processes

and Workflows with Smartsheet
By adopting business process modeling notation, you’re taking the first step in ensuring that
your processes are as efficient as possible. Once you’ve standardized your BPMN, you
need a collaborative work management solution to actually manage the work.

One such tool is Smartsheet, an enterprise work execution platform that fundamentally
changes the way teams, leaders, and businesses get work done. Over 74,000 brands and
millions of information workers trust Smartsheet as the best way to plan, capture, manage,
automate, and report on work.

You can build automated business processes without a single line of code, complex
formulas, or help from IT. Achieve faster progress by creating automated approval requests
and automated update requests that are triggered based on preset rules. Use Smartsheet to
automate and streamline the following processes: time card tracking, sales discounts,
procurement, HR hiring, content, and more. Plus, Smartsheet integrates with the tools you
already use, to seamlessly connect your efforts across applications.

Get from idea to impact, faster, by building powerful, automated business processes in
Smartsheet.