Blog

Standardizing BPMN Labels

Read Time: 4 Minutes

In my BPMN Method and Style training, I show the following BPMN and ask students, “What does this diagram say?”

Bruce Silver's blog - Standardizing BPMN Labels

You really cannot tell. It says something happens and then either the process ends or something else happens. Not very informative. But if you run Validation against the rules of the BPMN spec… no errors!

As far as the spec is concerned, it’s perfect. But if the goal is to communicate the process logic, it’s useless. If we run Validation against the Method and Style rules, we get this:

Now we get 6 errors, and they all pertain to the same thing: labels. Compare that process diagram with one containing labels and other “optional” elements:

Now the diagram says something meaningful. Beyond labels, the BPMN spec considers display of task type icons, event triggers, message flows, and black-box pools to be optional. Their meaning is defined in the spec, but modelers may omit them from the diagrams. Labels – their meaning, placement, or suggested syntax – are not discussed at all. They are pure methodology.

Obviously, to communicate process logic intelligibly through diagrams, labels and similar methodological elements are necessary. That was the main reason I created my own methodology, called Method and Style, over a decade ago, which includes rules about where labels are required, what each one means, and where corresponding diagram elements must be labeled identically. The best BPMN tools, like Trisotech Workflow Modeler, have Method and Style Validation built in, and thousands of students have been trained and certified on how to use it.

Here are some of the rules related to labeling:

Activities should be labeled (Verb-object) to indicate an action.
A Message start event should be labeled Receive [message name].
A Timer start event should be labeled with the frequency of occurrence.
The label of a child-level page should match the name of the subprocess.
Two activities in the same process should not have the same name unless they are identical.
A boundary event should be labeled.
An Error or Escalation boundary event on a subprocess should be labeled to match the throwing Error event.

A throwing or catching intermediate event should be labeled.
If a process level has multiple end events, each end event should be labeled with the name of the end state (Noun-adjective).
Each gate of an XOR gateway should be labeled with the name of an end state of the previous activity. If 2 gates, the gateway may be labeled as end state plus ? and the gates labeled yes and no.
Gates of an AND gateway should not be labeled.
Non-default gates of an OR gateway should be labeled.
Two end events in a process level should not have the same name. If they mean the same end state, combine them; otherwise give them different names.

One reason why the task force developing the BPMN 2.0 standard didn’t care about labels is that their focus was primarily on model execution, which depends heavily on process data. While it is possible to suggest process data and data flow in the diagrams, this is something that – in most tools – is defined by Java programmers, and as a consequence is omitted entirely in descriptive, i.e. non-executable, models. In order to reveal model meaning in descriptive models in the absence of process data, Method and Style introduced the concept of end states.

The end state of an activity or process just means how did it complete, successfully or in some exception state. End state labels, typically in the form Noun-adjective, serve as a proxy for the process data used to determine branching at gateways. For example, in the diagram above, the gate labels Valid and Invalid are by convention the end states of the preceding activity Validate request. An executable version of this process would not necessarily have a variable with those enumerated values, but the labels suggest the process logic in an intuitive way.

I’m not going to review the other Method and Style conventions and rules here. There is plenty of information about them on my website methodandstyle.com, my book BPMN Quick and Easy, and of course my BPMN Method and Style training. Method and Style makes the difference between BPMN diagrams that communicate the logic clearly and completely and those that are incomplete and ambiguous. BPM project team managers tell me that before Method and Style, their BPMN diagrams could be understood only by the person that created them. Standardization of the meaning and usage of diagram labels changed all that.

CMMN, the case management standard, has the same issue. For example, a plan item’s entry and exit criteria, modeled using sentries and ON-part links, require labels on both the ON-part (a standard event) and the IF-part (a data condition) to make sense, but labeling is not required or even suggested by the spec. Without labels, all we can tell is that some entry or exit condition exists. My book CMMN Method and Style suggests several labeling conventions for those diagrams, as well.

The Trisotech platform provides a key benefit to Method and Style practitioners: Method and Style rules about labels and other conventions can be checked in one click. Style rule validation not only improves model quality but reinforces the rules in the modeler’s mind. In the training, certification exercises must be free of any validation errors.

If your BPM project depends on shared understanding of BPMN diagrams, you need to go beyond the spec with labeling standards. You need Method and Style.

Follow Bruce Silver on Method & Style.