Naming Conventions
There are no official BPMN naming conventions, but here are some best practices:
For all objects:
-
Use keywords that are meaningful to the organization
-
Do not use uncommon abbreviations
-
Do not use the object type in its name
-
Avoid articles and pronouns
Activities
-
Name them all
-
Name them with a Verb-Noun phrase {e.g. "Enter Order")
-
Use the present tense of an active verb of meaning to the organization
-
Use a qualified noun of meaning to the organization
-
Do not name multiple Activities with the same name (except for Call Activities)
Gateways
-
Gateways do not perform any work or make decisions; they simply depict the divergence or convergence of flow
-
Do not name converging Gateways
-
Associate a Text Artifact when convergence logic is not obvious
-
Name diverging Exclusive Gateways with an interrogative phrase (e.g. "Is Order Large")
Sequence Flows
-
Name Sequence flows coming out of diverging Gateways using their associated conditions stated as outcomes (e.g. "Less than $1,000", "$1000 & More")
Events
-
All Events should be named
-
Name Message Events with a past participle using an active verb
-
Name Timer Events using their schedule
-
Name End Events using the name of the end state
Pools
-
Name Pools using the Participant's name or Process name
Lanes
-
Name Lanes using roles (e.g., Manager), systems (e.g., an application), or organizations (e.g., shipping)
BPMN Best Practices
Process Scope
-
Clearly define the scope of the Process by identifying the Who, What, When, Where and Why of your process (the Process is the How)
-
Identify the potential alternative ways to trigger the Process using Start Events
-
Identify the potential alternative end states of the instances of the Process using End Events
Diagram layouts
-
Aim for BPMN Diagrams that fit one page
-
Layout your BPMN Diagrams neatly to ease readability by minimizing flow crossing
-
Use consistent layout with horizontal Sequence Flows and vertical Message Flows
-
BPMN Diagrams can loop back but most readers expect a left-to-right ordering
-
Do not create zigzag layouts of elements
-
It should be clear what the primary ("Happy") path of the Process is
-
Whenever possible, externalize the business rules from the Process to create more concise and more agile Process models using Business Rule Tasks
-
Create alternative visualizations of the same Process for different communication purposes and stakeholders. For example:
-
A summary Diagram with all Sub-Processes and Call Activities collapsed
-
A verbose Diagram with all Sub-Processes and Call Activities expanded
-
Process Partitioning and Structure
-
To describe Process in-depth, use Collapsed Sub-Processes to define hierarchical Process layers of detail
-
Use Call Activities to re-use other Processes
Start and End Events
-
Always use Start and End Events
-
Distinguish alternative instantiation of the process as separate Start Events
-
Distinguish various end states as separate End Events
-
Flows that end in the same end state should be merged to the same End Event
Gateways
-
Always use Gateways to depict split or merge of flows
-
Do not use mixed mode Gateways (both diverging and converging)
-
Always place an Activity that will determine the diverging condition(s) just before a diverging Gateway
Manual, Automated and Semi-automated Tasks
-
Use a Manual Task to depict work effort expected to be performed without the aid of any software application
-
Use a User Task to depict semi-automated work effort where a human performer uses a software application to complete the Task
-
Use an Automated Task to depict word done by a system or application