Naming BPMN Elements

Name all elements in your BPMN diagrams by focusing on the business perspective. For activities, use a verb to describe what to do. For events, describe in which (business) state the process or domain object is currently in. For (data based) gateways, pose a question and describe the conditions under which the process moves on along the outgoing flows.
Naming BPMN Elements
You must You should You may

Name Activities

Name Events

Name Gateways

Name Processes

Use Sentence Case

Avoid Technical Terms

Avoid Abbreviations

Naming Activities

Name a task using an object and a verb in the infinitive. By doing that you consistently describe what you do with an object.

Name a subprocess (or call activity) by using an object and a - by convention nominalized - verb. Similar to tasks you should always describe what you do with an object.

Avoid very broad and general verbs like e.g. "Handle invoice" or "Process order" and try to be more specific about what you do in your activity from a business perspective.

Naming Events

Wherever possible, name an event by using an object and a verb reflecting a state. Always try to describe in which state an object is when the process is about to leave the event.

This naming approach does not always work 'perfectly'. In those cases try to precisely describe the business semantics when the process is about to leave the event. The following names are also "good enough":

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:

1 'Invoice paid' better qualifies the "successful" business state than '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'.
Avoid very broad and general verbs like e.g. "Invoice processed" or "Order handled"!

Naming Gateways

Name a data based exclusive gateway by using a question. Name the outgoing sequence flows by using the condition under which each of them is executed. Try to describe the conditions as answers to the question posed at the gateway.

This naming approach does not always work for an inclusive gateway, because the outgoing flow’s conditions can be completely independent from each other. Still use a question whenever possible.

If this is not possible, leave out the question completely but describe the conditions under which the outgoing paths are executed.

Avoid naming event based gateways, but ensure you name their subsequent events. Also, avoid naming parallel gateways and all forms of joining gateways. You don’t need to specify anything about those gateways, as the flow semantics are always the same.

Naming Processes

A pool should be given the same name as the process the pool contains, by using an object and a nominalized verb. Optionally add the organizational role which is responsible for the process shown in the pool as a whole.

In case you have more than one lane in a pool, name each lane by using the organizational role or technical system which is responsible for carrying out the activities shown in the lane.

Name a diagram (file) with same name as process shown in the diagram. In case of a collaboration diagram, use a name reflecting the end-to-end perspective shown in that diagram.

Using Sentence Case

Use sentence case when naming BPMN symbols. It is standard capitalization of an English sentence, with the first letter uppercase and subsequent letters lowercase with exceptions such as proper nouns or acronyms. Examples:

1 Prepare dinner
2 Every family member

Avoiding Technical Terms

Avoid to use purely technical terms when naming e.g. activities or other BPMN symbols - they are not always clear to every reader. Completely avoid using names of coding artifacts like classes, methods and technical services or purely technical systems.

Avoiding Abbreviations

Avoid using abbreviations - they are not always clear to every reader. This is especially true for abbreviations which are company or department specific. Try to avoid them completely.

If you want to use an abbreviation in your model, normally only in order to save space or sometimes even to improve understandability, make sure you explain it in the model (either in brackets or by text annotations) or use a commonly accessible glossary.

No guarantee - The statements made in this publication are recommendations based on the practical experience of the authors. They are not part of Camunda’s official product documentation. Camunda cannot accept any responsibility for the accuracy or timeliness of the statements made. If examples of source code are shown, a total absence of errors in the provided source code cannot be guaranteed. Liability for any damage resulting from the application of the recommendations presented here, is excluded.

Copyright © Camunda Services GmbH - All rights reserved. The disclosure of the information presented here is only permitted with written consent of Camunda Services GmbH.