News from the project

Validate and Improve your BPMN Diagrams with bpmnlint

Published by Seif Ghezala on Thursday, 11 October 2018.


Today we are excited to reveal bpmnlint, a linting and validation tool which helps you to check and improve your BPMN diagrams based on configurable rules.

BPMN is a powerful language for visualizing processes and collaboration. Often, it allows you to express a certain interaction in a number of ways, one way harder to understand than the other. Sometimes the same modeling pattern is expressed in different ways, making it harder to recognize it across your diagrams. Ever so often you may even end up creating BPMN diagrams that are syntactically incorrect, incomplete or completely not understandable for the uninitiated reader.

In this context, bpmnlint steps in. It validates your diagram against a defined set of rules and reports these as errors or warnings. It may check your BPMN diagrams from the command line or run integrated into our BPMN modeler via bpmn-js-bpmnlint:

bpmnlint validating a diagram as you model.

Rules at the Core

Rules to detect certain patterns in BPMN diagrams are at the core of the library. Each rule is defined by a piece of code that may detect and report anything from label missing to the fact that a specific error prone modeling pattern got detected.

To give you a better taste of what a rule may be, here is the list of rules built into the library as of today:

Rule Name Description
conditional-flows Reports outgoing flows with missing conditions.
end-event-required Reports missing end events.
fake-join Reports an implicit join that actually is none.
label-required Reports missing labels.
no-complex-gateway Reports complex gateways.
no-disconnected Reports unconnected elements.
no-gateway-join-fork Reports gateways that fork and join at the same time.
no-implicit-split Reports implicit splits.
no-inclusive-gateway Reports inclusive gateways.
single-blank-start-event Reports multiple blank start events in a scope.
single-event-definition Reports events with multiple definitions.
start-event-required Reports missing start events.

In addition to these rules, we got a few ones we intend to implement.

Are there common modeling errors that you experienced? Could these errors be avoided with bpmnlint? Propose a new bpmnlint rule and help us to build a strong foundation for BPMN diagram validation.

From Zero to bpmnlint

Let us get a better understanding of bpmnlint's configuration and extensibility. To get started, checkout and run the bpmnlint-playground, a project designed specificly to play around with the model validation project.

git clone

cd bpmnlint-playground

npm install
npm start

Executing npm start opens a browser window with the playground app that has linting support baked in.

Configure Available Rules

A .bpmnlintrc file placed in your current working directory defines which rules to apply and whether to treat them as errors or warnings. The playground holds a .bpmnlintrc that looks like this:

  "extends": [
  "rules": {
    "playground/no-manual-task": "warn"

The extends block tells bpmnlint to inherit the configuration from two pre-defined rule sets: bpmnlint:recommended and playground/recommended, the later provided by the playground plug-in.

The rules block overrides reporting for a specific rule. The example configures the playground/no-manual-task as a warning (rather than an error). We could pick any rule, e.g. a built-in one, and turn it off entirely, too:

  "rules": {
    "bpmnlint/label-required": "off"

In the playground app, we can see that the linter won't report start events without labels anymore.

Create Custom Rules

Customizing reporting of existing rules is great, but it does not satisfy every use case. Sometimes, a user or an organization wants to identify domain specific patterns, relevant to their particular style of modeling. bpmnlint solves this issue by allowing you to contribute custom rules and rule sets.

For instance, what if we want to have a rule that enforces having an emoji in the label of every flow node? Let us jump into the playgrounds plugin folder and create the emoji-label-required rule in the rules/emoji-label-required.js file:

const {
} = require('bpmnlint-utils');

const emojiRegex = require('emoji-regex');

 * Detect and report missing emojis in element names.
module.exports = function() {

  function check(node, reporter) {
    if (isAny(node, [
    ])) {

      const name = ( || '').trim();

      if (!emojiRegex().test(name)) {, 'Element must have an emoji');

  return {

The rule exposes a check(node, reporter) function that simply reports whenever a BPMN label is missing an emoji. The emoji-regex utility carries out the check for us. We must install it as a dependency inside the plug-in directory to get the rule running:

cd plugin
npm install emoji-regex

Then, we need to adjust our configuration to use the emoji-label-required rule. Since is not a built-in rule, we prefix it with its plugin name (in this case playground):

  "rules": {
    "playground/emoji-label-required": "error"

Going back to the playground app the linter will now report an error for labels without emojis:

Validating the presence of emojis in labels.

This completes our quick walk through bpmnlint's extensibility.

Check out the playgrounds emoji-label-required branch that contains the implementation described in this blog post. To learn more about rule packaging and testing have look at the example plug-in.

Wrapping Up

bpmnlint is a BPMN diagram validator that can be used as command line tool or integrated into bpmn-js using the bpmn-js-bpmnlint extension. In the future, we plan to also make it available as a Camunda Modeler plugin.

Try out the tool and help us to improve it by reporting rules you'd like to see supported.

Go ahead and start validating your diagrams today !

Are you passionate about JavaScript, modeling, and the web?
Join Camunda and build modeling tools people heart.