Camunda Modeler Anleitung: wie modelliere, prüfe und deploye ich BPMN, DMN und Formulare?

Der Camunda Modeler ist eine Anwendung, in der Sie ein BPMN-Diagramm zeichnen, eine DMN-Entscheidungstabelle aufbauen und ein Formular gestalten, alles im selben Werkzeug. Darin prüfen Sie das Modell, bevor Sie es deployen: Sie laden es auf eine Engine, die den Prozess ausführt. Dieser Beitrag geht die Schritte der Reihe nach durch, modellieren, prüfen, deployen, und zeigt, wohin ein Modell am Ende laufen kann.

Camunda fasst das Werkzeug in einem Satz zusammen: „Desktop Modeler (also known as Camunda Modeler) is a desktop application for modeling BPMN, DMN, and Forms.“ Der Quelltext steht unter der MIT-Lizenz, und dieselbe Anwendung bedient Camunda 7 und Camunda 8.

Ein Punkt räumt die meisten Missverständnisse aus. Eine Installation deckt beide Generationen ab, doch ein Modell, das für Camunda 7 gezeichnet wurde, durchläuft eine Konvertierung, bevor es auf Camunda 8 läuft. Dafür bietet Camunda einen eigenen Diagram Converter an, der laut Dokumentation BPMN-, DMN- und Camunda-7-Formulardateien analysiert und konvertiert. Zudem wechselt die Ausdruckssprache: Camunda 7 nutzt JUEL, Camunda 8 nutzt FEEL (docs.camunda.io, Conceptual differences).

Was der Desktop Modeler laut Camunda kann

Die Funktionsliste in der Dokumentation (docs.camunda.io, Desktop Modeler) nennt sechs Punkte:

• „Design BPMN, DMN, and Forms“
• „Implement process applications for Camunda 7 and 8“
• „Deploy and run processes directly from the application“
• „Validate your diagrams using configurable lint rules“
• „Customize and extend the application“
• „Work against the local file system“

Zwei dieser Punkte wiegen im Alltag schwerer als die übrigen vier. Die konfigurierbaren Lint-Regeln fangen Modellierungsfehler ab, bevor ein Prozess läuft. Und weil der Modeler mit dem lokalen Dateisystem arbeitet, können Ihre .bpmn-Dateien im selben Repository liegen wie Ihr Code, mit derselben Historie und demselben Review.

Deshalb legen wir Prozessmodelle ins Code-Repository. Ein Prozessmodell ist Quellcode und gehört in dieselbe Versionsverwaltung wie alles andere, was in Produktion läuft.

Hier liegt auch der praktische Unterschied zum Web Modeler. Der Desktop Modeler arbeitet mit Dateien auf Ihrem eigenen Rechner und passt deshalb, wenn die Modelle im selben Git-Repository liegen wie der Code. Der Web Modeler ist ein eigenes Camunda-Produkt mit eigenen Lizenzbedingungen, die der Abschnitt zur Lizenz weiter unten beschreibt.

Download, Plattformen und aktuelle Version

Camunda bietet die Anwendung auf der eigenen Downloadseite für Windows, Linux und macOS an. Nach dem Herunterladen entpacken Sie das Archiv und starten die Anwendung direkt. Unter Windows und Linux können Sie den Modeler zusätzlich als Standardeditor für BPMN-, DMN- und Formulardateien registrieren (docs.camunda.io, Desktop Modeler).

Neue Versionen erscheinen in kurzen Abständen. Version 5.52.0 hat Camunda am 6. Oktober 2026 auf GitHub veröffentlicht, und am 28. Oktober 2026 war sie dort die neueste Version. Laut Changelog führt sie Camunda 8.10 als neuestes stabiles Engine-Profil und liefert keine 32-Bit-Pakete für Windows mehr aus.

Camunda 8.10 ist laut den Release Notes von Camunda 8 im Oktober 2026 erschienen. Für Camunda 7 verzeichnet der Changelog die Unterstützung von Camunda 7.24 ab Modeler 5.35.0 und führt 7.24 ab Version 5.40.0 als stabil.

Die Dokumentation von Camunda 7 verweist für den Modeler inzwischen auf eine andere Adresse. Ihre Modeler-Seite für 7.24 sagt: „This content has moved to docs.camunda.io and is available here for all future versions“ (docs.camunda.org, Camunda Modeler). Die aktuelle Modeler-Dokumentation für beide Generationen finden Sie deshalb auf docs.camunda.io.

BPMN-Diagramme modellieren

Ein BPMN-Diagramm besteht aus Elementen, die Sie im Modeler per Klick oder Ziehen auf die Zeichenfläche setzen und mit Pfeilen verbinden. Ein Startereignis markiert, wo der Prozess beginnt, eine Aufgabe steht für einen Arbeitsschritt, ein Gateway für eine Verzweigung, und ein Endereignis markiert den Abschluss. Die Pfeile zwischen den Elementen heissen Sequenzflüsse: Sie legen fest, in welcher Reihenfolge der Prozess durch die Elemente läuft.

Jedes Element trägt neben seiner Form auch technische Angaben, die im Hintergrund als XML gespeichert werden. Diese Angaben sagen einer Engine, was an diesem Element zu tun ist, zum Beispiel welchen Programmcode sie an einer Aufgabe aufruft oder welche Bedingung an einem Gateway entscheidet.

Welche Elemente und Symbole BPMN insgesamt kennt und welche davon eine Engine tatsächlich ausführt, steht in BPMN 2.0: die Elemente, die Sie tatsächlich brauchen.

DMN-Entscheidungstabellen erstellen

Neben dem BPMN-Diagramm bildet der Modeler auch DMN ab, die Notation für Entscheidungstabellen. Eine Entscheidungstabelle legt fest, welche Eingaben zu welchem Ergebnis führen: Zeile für Zeile, Bedingung für Bedingung. Sie lagern die Regel damit in eine eigene Tabelle aus, getrennt vom Prozessdiagramm.

Ein Task im BPMN-Diagramm verweist dann auf diese Tabelle. Wenn der Prozess an dieser Stelle ankommt, wertet die Engine die Tabelle aus und liefert das Ergebnis an den Prozess zurück. Das trennt die fachliche Regel, die sich ändern kann, von dem Ablauf, der meist stabil bleibt.

Der Modeler zeigt die Tabelle als Raster aus Spalten und Zeilen, mit Bedingungen auf der einen Seite und dem Ergebnis auf der anderen. Sie bearbeiten sie direkt in diesem Raster, ohne eine eigene Programmiersprache zu lernen.

Formulare gestalten

Der Modeler deckt laut Camunda auch das Design von Formularen ab. Ein Formular sammelt oder zeigt Daten an einer bestimmten Stelle im Prozess, etwa wenn eine Person eine Aufgabe bearbeitet und dafür Angaben eintragen oder Angaben aus dem Prozess sehen muss.

Sie setzen das Formular aus einzelnen Feldern zusammen, etwa Textfeldern, Auswahllisten oder Kontrollkästchen, und ordnen es einem Task im BPMN-Diagramm zu. Beim Ausführen zeigt die Engine dieses Formular der Person, die die Aufgabe bearbeitet.

Diagramme prüfen und validieren

Der Camunda Modeler prüft Ihr Diagramm mit konfigurierbaren Lint-Regeln. Camunda beschreibt diese Funktion so: „Validate your diagrams using configurable lint rules“. Diese Regeln laufen, während Sie zeichnen, und sie zeigen an, wo ein Element fehlt, wo eine Verbindung offen bleibt oder wo ein Ausdruck eine Form verletzt, die die Engine erwartet.

Die Lint-Regeln prüfen die Form des Modells. Ob das Diagramm den Ablauf abbildet, den die verantwortlichen Personen gemeint haben, prüfen in der Abnahme die Menschen, die den Prozess kennen: Sie lesen das Diagramm Schritt für Schritt und sagen, ob es den tatsächlichen Fall trifft, auch die Ausnahmen.

Beide Prüfungen gehören vor das Deployment.

Deployment zu Camunda 7, Camunda 8 und weiteren Engines

Der Modeler listet als Funktion „Deploy and run processes directly from the application“ und „Implement process applications for Camunda 7 and 8“. Sie zeichnen das Diagramm einmal und wählen dann, wohin Sie es deployen. Für einen produktiven Bestand lohnt sich daneben ein Deployment-Schritt in der eigenen Build-Pipeline, mit Versionsverwaltung und Review, der sich wiederholen und nachvollziehen lässt.

Welche Engine am anderen Ende der Pipeline steht, ist eine eigene Entscheidung. Für ein Diagramm, das heute auf Camunda 7 läuft, nennt unser Handbuch mehrere Wege: auf Camunda 7 Enterprise bleiben, zu Camunda 8 wechseln, zu einem Fork wechseln, zu Flowable wechseln, oder BPMN durch eine andere Form dauerhafter Ausführung ersetzen.

Wir setzen Camunda 8 und CIB seven um, und wir arbeiten mit Operaton und Flowable. Welcher dieser Wege zu Ihrem Bestand passt, hängt an den technischen Angaben in Ihrem Modell und an Ihrem bestehenden Code.

Lizenz: Desktop Modeler und Web Modeler

Der Desktop Modeler, die Anwendung, mit der Sie BPMN, DMN und Formulare zeichnen und prüfen, steht unter der MIT-Lizenz. Das Repository camunda/camunda-modeler trägt diese Lizenz und ist nicht archiviert, und der letzte Push war am 28. Oktober 2026. Alle drei Angaben haben wir an diesem Tag über die GitHub API geprüft. Camundas Lizenzübersicht bestätigt die Lizenz: „The source code of Desktop Modeler is licensed under the MIT license as stated in the LICENSE file in the root of the source code repository.“ Und weiter: „This file is also shipped as LICENSE.camunda-modeler.txt with each modeler distribution.“ Für die Nutzung des Desktop Modelers brauchen Sie keine kommerzielle Lizenz.

Für den Web Modeler gilt eine andere Lage. Camunda schreibt in der eigenen Lizenzübersicht, der Quelltext von Web Modeler und Console stehe unter einer proprietären Lizenz und sei „only available to users or customers on demand“. Die kompilierte Software dieser Komponenten verteilt Camunda ebenfalls unter einer proprietären Lizenz, entweder der Camunda Self-Managed Non-Production license oder der Lizenz der Camunda Self-Managed Enterprise Edition. Für den produktiven Einsatz verweist die Seite auf den Kauf der Camunda Self-Managed Enterprise Edition (docs.camunda.io, Licensing).

Wer den Desktop Modeler und den Web Modeler in einer Beschaffungsunterlage als ein Produkt führt, führt zwei Lizenzen unter einem Namen. Für eine Entscheidung über das Werkzeug lohnt sich der Blick in die jeweilige Lizenzdatei, bevor Sie eine Annahme über Kosten oder Zugriff treffen.

Was der Modeler Ihnen zur Entscheidung überlässt

Drei Fragen in einem Camunda-Projekt liegen ausserhalb des Werkzeugs. Hier stehen sie in der Reihenfolge, in der sie meist aufkommen.

Die Zeile zu den Ausdrücken lohnt einen genaueren Blick. Camundas Migrationsleitfaden hält fest: „Camunda 7 uses Java Unified Expression Language (JUEL) as the expression language.“ Und: „Camunda 8 uses Friendly-Enough Expression Language (FEEL) and expressions can only access the process instance data and variables.“ Läuft die Engine von Camunda 7 eingebettet in Ihrer Anwendung, können Ausdrücke laut Leitfaden sogar auf Java-Objekte der Anwendung zugreifen: „expressions can even read into beans (Java object instances) in the application“. Die meisten Ausdrücke lassen sich laut Camunda konvertieren („Most expressions can be converted“), andere müssen Sie unter Umständen ganz neu schreiben („you may need to completely rewrite others“). Eine Gateway-Bedingung, die in Camunda 7 eine Bean liest, ist ein Kandidat für eine solche Neufassung, bevor sie auf Camunda 8 läuft (docs.camunda.io, Conceptual differences).

Die dritte Zeile stützt sich auf denselben Leitfaden. Camunda 7 erlaubt, die Engine als Bibliothek in Ihre Anwendung einzubetten. In Camunda 8 ist die Engine Zeebe dagegen „always a remote resource for your application“, und es gilt: „Camunda 8 only allows storage of primary data types or JSON as process variables.“ Diese Unterschiede schlagen sich im Java-Code nieder. Für die Modelle selbst beschreibt Camunda den Diagram Converter als Werkzeug, das BPMN-, DMN- und Camunda-7-Formulardateien analysiert und konvertiert. Sie können es lokal installieren (Java oder Docker) oder als kostenlosen gehosteten Dienst nutzen.

Grenzen beim Wechsel auf Camunda 8

Unser Handbuch listet Funktionen von Camunda 7, zu denen Camunda 8 keine Entsprechung hat.

Wenn Sie ein Modell öffnen, das für Camunda 7 gebaut wurde, und es für Camunda 8 weiterverwenden wollen, prüft der Modeler dessen Syntax. Ob eine bestimmte technische Eigenschaft des Modells auf der Zielengine dieselbe Bedeutung trägt, entscheidet sich in der Dokumentation der Zielengine und im Abgleich mit Ihrem Bestand.

Welche Eigenschaften dabei im Einzelnen betroffen sind, beschreibt Camunda 7 vs. Camunda 8.

Wo Camunda 7 steht, während Sie dafür modellieren

Die Community Edition von Camunda 7 hat im Oktober 2025 ihr End of Life erreicht. Ihr letztes Feature-Release, 7.24, hatte Camunda für den 14. Oktober 2025 angekündigt (Camunda Forum), und der Eintrag für camunda-engine 7.24.0 auf Maven Central lautet: „Note: 7.24.0 is the last community edition release published on Maven Central“ (Maven Central, camunda-engine 7.24.0). Für die Enterprise Edition schreibt Camunda auf der eigenen Migrationsseite: „Camunda 7 Enterprise Edition remains supported through April 2030, but we recommend all new projects be developed on Camunda 8“ (camunda.com/platform-7/migrate).

Die Modeler-Dokumentation nennt weiterhin Camunda 7 und 8 als Ziel. Alle Termine je Version stehen in Camunda 7: Wartungsende je Version, und das Gesamtbild der beiden Produkte in Was ist Camunda?.

Soll der Prozess hinter Ihrem Diagramm ohne Ihr Zutun laufen, können Sie diesen Prozess automatisieren lassen, der zwei Wochen nach dem Kickoff-Workshop live ist.