Professional Documents
Culture Documents
Best Practices p1
Best Practices p1
Version: 8.5
Essential practices
Labeling BPMN elements
Use conventions for naming BPMN elements; this will consistently inform the reader of the business semantics. The clarity and meaning of a process
is often only as good as its labels.
Send rejection
notification
Tweet rejected
No
2
3
1 Yes 5
Publish on
Review tweet
Twitter
New Tweet
4 Tweet published
Tweet approved?
written
Tweet duplicated
Handle
duplicate tweet
1 Start event labels informs the reader of how the process is triggered.
2 An activity - labeled as "activity" - informs the reader of the piece of work to be carried out.
3 Gateway labels clarifies based on which condition(s) and along which sequence flow the process proceeds.
4 Labeled boundary events clearly express in which cases a process execustion might follow an exceptional path.
5 Labeled end events characterize end results of the process from a business perspective.
Recommended practices
Modeling symmetrically
Try to model symmetrically. Identify related splitting and joining gateways and form easily recognizable visual, eventually nested, blocks with those
gateways.
Lunch Lunch
time finished
Salad Steak
Stir-fry steak
Prepare salad
1 The inclusive gateway splits the process flow into two paths which are ...
2 ... joined again with an inclusive gateway. Inside that block ...
3 another exclusive gateway splits the process flow into two more paths which are ...
4 ... joined again with an exclusive gateway. Ask AI
By explicitly showing pairs of gateways "opening" and "closing" parts of the process diagram, and by positioning such gateway pairs as
symmetrically as possible, the readability of process model is improved. The reader can easily recognize logical parts of the diagram and quickly
jump to those parts the reader is momentarily interested in.
No
Review Yes
objection
Objection
No
received
Hand over to
collection
agency
Objection
period lapsed
Modeling from left to right supports the reading direction (for western audience) and supports the human field of vision - which prefers wide
screens.
Avoid sequence flows violating the reading direction, meaning no outgoing flows on the left or incoming flows on the right of a symbol.
Customer
Order complete? credit-worthy?
Check
Check order Yes customer's Yes Determine Fax order
completeness credit- delivery date confirmation
worthiness
Order received No No Order confirmed
Order not Customer ID Ordered good Fax number
readable non-existent not deliverable wrong
2
1
Correct fax
number
Order declined
1 The author could have made the five (!) sequence flows leading into the end event visible by separating them. However, by consciously
choosing to partly overlap those flows, this model becomes less cluttered, therefore less confusing and easier to read.
2 The author could have attached the sequence flow, leaving this task on its left. However, this would have decreased readability, because the flow
connection violates the reading direction. The same applies to incoming flows on the right of a symbol.
Avoid flows crossing each other and flows crossing many pools or lanes, wherever possible. Rearrange the order of lanes and paths to make your
sequence flows more readable. Oftentimes, removing lanes can improve readability! Rearrange the order of pools in a collaboration diagram to
avoid message flows crossing pools as much as possible. Often, you will find a "natural" order of pools reflecting the order of first involvement of
parties in the end-to-end process. This order will often also lead to a minimum of crossing lines.
Avoid very long (multi page) sequence flows, especially when flowing against the reading direction. The reader will lose any sense of what such lines
actually mean. Instead, use link events to connect points which are not on the same page or screen anymore.
1 2
Recourse not Recourse not
possible possible
No
Review Yes
objection
Objection
No
received
Hand over to
collection
agency
Objection
period lapsed
Modeling explicitly
Make your models easier to understand by modeling explicitly, which most often means to either completely avoid certain more "implicit" BPMN
constructs, or at least to use them cautiously. Always consider the central goal of increased readability and understandability of the model when
deciding whether to model explicitly or implicitly. When in doubt, it's best to favor an explicit style.
Model splitting the process flow by always using gateway symbols like instead of conditional flows .
Lunch Lunch
time finished
Salad Steak
Stir-fry steak
Prepare salad
1 For example, you could've left out this inclusive gateway by drawing two outgoing sequence flows directly out of the preceding task Choose
menu and attaching conditions to those sequence flows (becoming conditional sequence flows ). However, experience shows that readers
understand the flow semantics of gateways better, which is why we do not make use of this possibility.
Modeling start and end events
Model the trigger and the end status of processes by always explicitly showing the start and end event symbols.
1 2
Choose
Order pizza Pay for pizza Eat pizza
pizza
Inquire with
pizza service
60 minutes
CAUTION
Process models without start and end event cannot be executed on the Camunda workflow engine
1 According to the BPMN standard, you could have left out the start event...
2 ...as long as you also leave out the end events of a process. However, you would have lost important information in your model, which is why we
do not make use of this syntactical possibility.
Be specific about the state you reached with your event from a business perspective. Quite typically, you will reach "success" and "failure" like events
from a business perspective:
Invoice
correct?
Yes 1
Check invoice Pay invoice
No 2
Reject payment
of invoice
Invoice
rejected
1 'Invoice paid' better qualifies the "successful" business state than e.g. 'Invoice processed' would...
2 ...because in principle, you can call the failed state 'Invoice processed', too, but the reader of the diagram is much better informed by calling it
'Invoice rejected'.
Separating splitting and joining gateways
In general, avoid mixing up the split and join semantics of gateways by explicitly showing two separate symbols:
Lunch Lunch
time finished
No Steak
Stir-fry steak
1 You could have modeled this join implicitly by leaving out the explicitly joining XOR gateway and directly connecting two incoming sequence
flows to...
2 ...the subsequent splitting XOR gateway. Of course, BPMN would allow this for other gateway types, too. However, experience shows that
readers will often overlook the join semantics of such gateways serving two purposes at the same time.
The fact that readers will often overlook the join semantics of gateways serving to join as well as split the process flow at the same time, combined
with the preference for modeling symmetrically, leads us to prefer splitting and joining gateways modeled with separate symbols.
However, there are cases in which the readability of models can be improved with implicit modeling. Consider the following example:
Send rejection
notification
Tweet rejected
No
1
Yes Publish on
Review tweet
Twitter
Handle
duplicate tweet
1 The two incoming sequence flows to the task "Review tweet" could be merged with an XOR gateway, following explicit modeling. We argue that
a merging XOR gateway directly behind the start event decreases the readability. A merging XOR gateway is a passive element and the reader
expects the process to continue with an active element after the start event.
Using XOR gateway markers
Model the XOR gateway by explicitly showing the X symbol, even if some tools allow to draw a blank gateway.
Dish
selected?
1 2
Pasta
Choose menu Cook pasta Have lunch
Lunch Lunch
time finished
Steak
Stir-fry steak
Always model splitting the process flow by explicitly showing the gateway symbol:
Main dish
selected?
1 2
Pasta
Choose menu Cook pasta Have lunch
Lunch Lunch
time finished
Steak
Stir-fry steak
Prepare salad
1 You could have modeled this parallel split implicitly by leaving out the gateway and drawing two outgoing sequence flows out of the preceding
task Choose menu. However, the reader needs deeper BPMN knowledge in order to understand this model. Additionally, for joining the parallel
flows...
2 ...you will always need the explicit symbol.
The fact that readers of models using parallelization will likely need to understand the semantics of a parallel join combined with the preference for
modeling symmetrically leads us to prefer explicit parallel gateways, too.
Model joining the process flow by explicitly showing the XOR gateway symbol so the reader does not have to know BPMN details to understand
how two incoming or outgoing sequence flows in a task behave. Additionally, this often supports the symmetry of the model by explicitly showing a
"relationship" of the splitting and joining gateways forming a visual "block".
Dish
selected?
2 1
Pasta
Choose menu Cook pasta Have lunch
Lunch Lunch
time finished
Steak
Stir-fry steak
1 You could have modeled this join implicitly by leaving out the gateway and directly connecting the two incoming sequence flows to the
subsequent task Have lunch. However, explicitly modeling the join better visualizes a block, the joining gateway semantically "belongs" to...
2 ...the earlier split. In case the reader is not interested in the details of dinner preparation but just in having dinner, it's easy to "jump" to the
gateway, "closing" that logical part of the model.
This is particularly helpful for models bigger than that example with many such (eventually nested) blocks. Consider the following model, showing
two nested blocks of gateways:
Courses Main dish
selected? selected?
1
Main Pasta
Choose menu Cook pasta Have lunch
Lunch Lunch
time finished
Salad Steak
Stir-fry steak
Prepare salad
1 Now, you couldn't have modeled this join implicitly, because it's directly followed by an inclusive gateway with very different join semantics.
Consistency of joining techniques is another reason why we prefer explicitly joining sequence flows in general.
There are always exceptions to the rule! There are cases in which the readability of models can be improved with implicit modeling. So don't be
dogmatic about explicit modeling; always aim for the most readable model. The following example shows a case of a model in which splitting and
joining points do not form natural "blocks" anyway. In such cases, it can be preferable to make use of implicit joining to improve the overall
readability!
Avoiding lanes
Consider avoiding lanes for most of your models all together. They tend to conflict with several of the best practices presented here, like Modeling
Symmetrically, Emphasizing the Happy Path and Creating Readable Sequence Flows. Apart from readability concerns, our experience also shows that
lanes make it more difficult to change the resulting process models and therefore cause considerably more effort in maintenance.
When modeling on an operational level, where showing the responsibility of roles matters most, we recommend to use collaboration diagrams with
several separate pools for the process participants instead of lanes.
Strategic level models (refer to BPMN Tutorial and Real-Life BPMN on details for modeling levels) - especially when they have a focus on
responsibilities and their borders.
Technical/executable models with a focus on human work-flow and its ongoing "ping pong" between several participants.
For these cases, also consider alternative methods to maintain and show roles:
As a visible part of the task name, e.g. in between squared brackets []: "Review tweet [Boss]".
CAMUNDA 7 ONLY
During execution you can remove this part of the task name if you like by using simple mechanisms like shown in the Task Name Beautifier so
it does not clutter your tasklist.
NOTE
Roles are part of your executable BPMN process model as technical attributes anyway - even if hidden in the BPMN diagram. For example, they
can be used during execution for assignment at runtime.
Helpful practices
Emphasizing the happy path
You may want to emphasize the "happy path" leading to the delivery of a successful process result by placing the tasks, events, and gateways
belonging to the happy path on a straight sequence flow in the center of your diagram - at least as often as possible.
Send rejection
notification
Tweet rejected
No
2 4
3
1 Yes 5
Publish on
Review tweet
Twitter
Handle
duplicate tweet
The five BPMN symbols belonging to the happy path are put on a straight sequence flow in the center of the diagram.
👎
Call next
Call service
service
... ...
Exception
occured skip
Retry ANTI Pattern
Retries left?
Action?
No cancel
Handle incident This is an ANTI PATTERN.
Yes
All operations use cases put into the model can be handled via Camunda tooling, e.g. by retrying or Camunda Operate.
Furthermore, model just one coherent process per pool (apart from event subprocesses, of course), even though BPMN in principle allows several
processes per pool. This improves readability by constituting a clear visual border around every process and by providing a natural space for
labeling that part of the end-to-end process in the pool's header.
Mail Room Invoicer
1
Invoice
Invoice clarification Clarification
correct? requested successful?
2 3
Invoice Invoices to be
approved? paid exist?
Yes Request No
payment
Invoice No invoices
approved to be paid
Invoices
to be paid
1 The Team Assistance is responsible for initial "Invoice Collection" as well as "Invoice Clarification" - if applicable. Those two processes are
modeled by using two separate pools for the team assistance, just as...
2 ...the approver can observe the "Invoice Approval" process in a separate pool and...
3 ...the managing director can observe the "Invoice Payment" process in a separate pool while the collaboration diagram as a whole shows the
business analyst that the overall end-to-end process works.
Using collaboration diagrams with separate pools for the process participants allows to explicitly show interaction and communication between them
by means of message flow and further improves readability by transparently showing the participants their own involvement in the end-to-end-
process. As a consequence, they do not need to fully read and understand the end-to-end process in order to read, understand, and agree to their
own involvement by looking at their own pools.
Invoice Clarification
correct? successful?
Paid invoices
Invoice should be
approved? archived
automatically
Check No Request invoice
Approver - Invoice approval
invoice clarification
Invoice Invoice 2
approval not approved
requested
Archived PDFs
Yes Request
payment
Invoice
approved
Invoices
to be paid
Invoices to be
paid exist?
Managing director - Invoice payment
No
No invoices
to be paid
1 A collapsed pool is used to represent a system which supports the process and/or carries out process tasks on its own. The pool could be
expanded later to model the internal system details, maybe even with the goal to execute a technical process flow directly with a BPMN capable
process engine.
2 A data store is used to represent a technical container meant to archive PDFs and store them for later retrieval.
3 Another data store is used to represent a container which could be a physical storage place for paper invoices to be paid at the moment but
could become a representation for business objects in a database with the object state "to be paid" in the future.
When choosing between those two options for modeling systems (data stores, collapsed pools) keep in mind that only pools represent processes
and therefore have the capability to be expanded and modeled in all their internal details later on.
Experience shows that many data objects and especially many data associations quickly clutter your process model and that visual noise reduces
readability - especially for less experienced readers.
You might find three practices helpful to find your own "right" amount of data visualization:
Payment correct?
Delivery Service - Payment Creation
Create new Check new Yes
Save payment
payment payment
Payment Payment
necessary created
1
No Reset new
payment 2
New Payments
payment
Adjustment details
Adjustment
possible?
Adjustment Specialist
- Adjustment Check
No
1 Cautiously use data objects and associations to show the most important data related aspects of your process. We could have modeled that all
the tasks in the "Payments Creation" process either read, update, or delete the "new payment", however we decided that we just want to point out
that the process works on a new payment object.
2 Use data stores for coupling processes via data. We could have modeled a lot of other tasks in the process that either read or update the
"payments", however, we decided to just point out the most important aspect for the process diagram, which is that the "Payments Creation"
process of delivery service is loosely coupled with the "Payments Processing" via commonly shared data.
3 Here we decided that it's helpful to know that this message does not only inform an adjustment possibility was checked, but that it also delivers
all the necessary details of the adjustment.
Avoiding changes to symbol size and color
Leave the size of symbols as it is by default. For example, different sizes of tasks or events suggest that the bigger symbol is more important than the
smaller one - an often unwarranted assumption. Instead of writing long labels, use short and consistent labels in line with your naming conventions
and move all additional information into BPMN annotations associated to your specific BPMN element.
Furthermore, avoid excessive use of colors. Experience shows that colors are visually very strong instruments and psychologically very suggestive, but
will typically suggest different things to different readers. Additionally, a colorful model often looks less professional.
However, there are valid exceptions. For example, you could mark the happy path through a process with a visually weak coloring:
Send rejection
notification
Tweet rejected
No
Yes Publish on
Review tweet
Twitter
Handle
duplicate tweet
Another case for useful coloring might be to make a visual difference between human and technical flows within a bigger collaboration diagram by
coloring the header bar on the left side of the pools.
Tags: BPMN