Appendix B_ BPMN Basics

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