Naming Conventions for BPMN Diagrams

Naming Conventions for BPMN Diagrams

A Business Process diagram is a powerful communication tool. Key to its communication effectiveness is the naming or labelling terminology used.

There are no official naming conventions in BPMN, but here are a few best practices recognized over the years:

Consistency is essential, when you adhere to a set of best practices, you should apply it toward the entire diagram(s) associated to the process.

You should name or label "almost" everything in your diagrams – not just Activities, but also Sub-Processes, Intermediate Events, Gateways, Sequence Flows, End Events and Message Flows. Some graphical elements require attributes, like the duration of a Timer Event, and this content may not be displayed in the diagram. If not, add a label to the Event that replicates that information. If you do not present it in the diagram, it doesn’t really count.

Processes labels should clearly describe their main purpose. Ensure that you do not use short names or abbreviations.

Following are proposed practices for the core graphical elements of BPMN.

Activities

All Activities should be named. A resource is going to be performing each Activity, and the name of the Activity should describe what action is performed.

Each Activity should be named using a Verb-Noun phrase that is short and meaningful. The verb used should use the present tense and be familiar to the organization. The noun has to be qualified and also of meaning to the business.

You should avoid articles and pronouns, adding unnecessary precisions, for example: "Add Order Lines" instead of "Add all Lines to the Order". Multiple Activities should not be named with the same name, except for same Call Activities used many time in the Process.

Events

In a Process diagram, all Events should be named. Events of type Message, Signal, Escalation, and Error Events should be named with a past participle using an active verb. Link Events should be named with a noun. The Link Events that are paired, one catching event and one or many sending events should use the same name. Other paired Events of type Message, Escalation, and Error should also share matching names.

Timer Events act on a specific time-date or schedule, this information should be used to name the event. A Conditional Event is triggered on a specific condition. This condition should be used for its naming.

A Process may have one or more End Events. It is recommended to use different names corresponding to their end state.

Gateways

Gateways do not perform any work or make decisions; it is simply a visualization of divergence or convergence of flow. Converging Gateways do not required to be named. When the convergence logic is not obvious, a Text Annotation should be associated to the Gateway.

Diverging Exclusive Gateway should be named with an interrogative phrase. The name should be composed of one verb, one object, and a question mark to identify what is being evaluated. You can even use questions to clarify the decision involved. Using the question mark helps to limit the amount of text you have to put in the diagram, as all conditions on the outgoing sequence flows read as a simple answer to the question of the gateway.

Sequence Flows

Sequence Flows coming out of diverging Gateways of type Exclusive, Inclusive and Complex should be named using their associated conditions stated as outcomes. The same naming convention applies to Conditional Sequence Flows.

Default Sequence Flows should not be named. This flow will be taken only if all other outgoing flow conditions are not met.

Data Objects

All Data Objects should be named. They should be named using a qualified noun that is the name of a business object or information object of meaning to the business.

Name multiple instances of the same Data Object (which are really Data Object References) using a matching name followed by the applicable State in square Brackets.

Participants

Participants are generally a business entity (e.g., a company, company division, or a customer) or a business role (e.g., a buyer or a seller) that controls or is responsible for activities within a business process. They are associated to Pools in a Collaboration diagram. Participants should be named using a qualified noun or a noun phrase.

Pools

A Pool represents a Participant in a Collaboration diagram. Therefore name Pools using the Participant’s name. Do not name Pools using the Process Name, considering that the Process includes all diagram elements inside and outside a specific Pool.

Lanes

Lanes are often used to categorize elements by Roles. They are often used for such things as internal roles (e.g., Manager, Associate), systems (e.g., an enterprise application), or internal departments (e.g., shipping, finance). Lanes should be named using the category’s name.

Roles

Roles should also be named using a qualified noun or noun phrase.

Integrated BPMN, CMMN and DMN – Combining Processes, Cases and Decisions

Published on June 25, 2015

Denis Gagné’s presentation on Integrated BPMN CMMN and DMN at the Business & Case Management Summit 2015.

BPMN MIWG Capability Demonstration Berlin 2015

Published on June 25, 2015

BPMN Model Interchange Working Group (BPMN MIWG) Interchange Capability Demonstration that took place on 17 Jun 2015 in Berlin.

Multi-Vendor BPMN Interchange Demonstration

Streamed live on June 17, 2015

The BPMN Model Interchange Working Group (BPMN MIWG) is holding it’s 3rd BPMN interchange capability demonstration. 3 interchange scenarios will be presented involving numerous vendors in each scenario.

bpmNEXT 2015: Trisotech BPM Graph – Semantic Layer for Business/IT divide

Published on May 7, 2015

bpmNEXT 2015: Trisotech BPM Graph – Semantic Layer for Business/IT divide presented by Denis Gagne, Trisotech

The Trisotech BPM Graph creates a semantic layer that allows the mapping of the expressed desired results (Ends) of an organization and the course of actions (Means) expressed in the organization’s business processes. This semantic layer is proposed as the missing link between the Business and IT divide to ensure a better Business and IT alignment. The Trisotech BPM graph provides a global context for Process Discovery, Modeling, Analysis and Execution. This semantic layer makes use of Ontologies to enable a mapping between (sometime more loosely defined) business views and their more structured and model driven counterparts from the world of IT. The BPM Graph lays down the foundations for the future of intelligent, goal oriented, agent based or semantic BPM.

BPM in Practice – Process Mining and Process Modeling

Published on April 27, 2015

What is the use of a modeled process if it does not reflect reality? Process mining turns traditional BPM on its head by analyzing the transactional records from the IT systems to automatically visualize the processes that actually take place. Process mining is a new approach that gains more and more traction.

Integrating Process Mining with Process Modeling will offer many benefits.

Watch our webinar with Anne Rozinat (Fluxican) and Denis Gagné (Trisotech).

Applying BPMN & BPSim to Process Analysis

Published on March 26, 2015

Discovery and Analysis for Case Management

Published on June 26, 2014

BPM & Case Management presentation at Summit 2014 in Washington by Denis Gagné.

BPSim The Interchange Format

Published on May 08, 2014

Business Process Simulation Interchange Standard

Introducing Trisotech BPMN Process Animator

Published on March 31, 2014

Introducing Trisotech BPMN Process Animator presentation at bpmNEXT 2014 by Denis Gagné.

BPMN + BPSim PEX Week 2014

Published on February 05, 2014

Intro presentation on BPMN and BPSim at the PEX Week 2014 Workshop by Denis Gagné.

La gestion des processus d’affaires

Published on March 27, 2013

La gestion des processus d’affaires. Un survol de sa pratique et de ses technologies.
French presentation to the Quebec City Chapter of IIBA Oct 2012.

Top of the page DMN Quick Start himss19