Rules of "Good" BPMN
A subprocess and a control branch may be used as an alternative to the attached event
Activities performed in different rhytms belong to different processes
Align process and activities instances
Arrange diagrams horizontally
Attach a sequence flow to any side of the activity box
Avoid double negations
Avoid micromanagement
Avoid sequence flows overlapping
Check subprocess result on exit
Diagram should fit one page
Disconnected sequence flows not allowed
Don't overuse black box pools
Don't overuse terminate event
Don't place more than one expanded pool at one diagram
Don't play with elements size
Don't save on gateways
Don't use "flows with diamonds"
Don't use converging inclusive gateways without a paired exclusive gateway
Don't use mixed gateways
Don't use timer event to depict expected activity duration
End event name should answer the question "how did the case end?"
Error event may be used to model business exceptions
Follow structured modeling rules
Intermediate event name should answer the question "what happened?"
Keep activities names short
Main process flow in a properly organized diagram tends to be V-shaped
Make parallel merge explicit
Make parallel split explicit
Make process start and end explicit
Model alternative paths with splitting and merging gateways
Model handover by a sequence flow
Model processes end-to-end
Model work by activity
Name process as a service
Show the happy path
Start event name should answer the question "what happened?"
Subprocess must be started by none event
Task name should answer the question "what should we do?"
Time should flow left to right
Use a dedicated process to catch the event initiated by external participant
Use a subprocess with a terminate or error error event to model veto power
Use collapsed subprocesses
Use conditional event to model collaboration
Use default flow only in executable models
Use event gateways with caution
Use task plus gateway to model human-made decisions
Use the same naming templates for processes and subprocesses