Camunda Platform examples: one directory per BPMN problem, one git tag per engine version

A catalogue of independent samples, not one application to adopt

Camunda Platform examples describes itself as a collection of focused usage examples intended to get you started quickly, and that description is the key to reading the repository. Each directory is a self-contained answer to one question about the engine, not a layer in a shared application.

The repository root makes the shape obvious. Alongside the familiar `pom.xml` and the licence files sit directories named `servicetask/`, `usertask/`, `scripttask/`, `spin/`, `dmn-engine/`, `bpmn-model-api/`, `cmmn-model-api/`, `startevent/`, `cockpit/`, `tasklist/`, `multi-tenancy/`, `migration/`, `deployment/`, `testing/`, `authentication/`, `clients/`, `sdk-js/`, `process-engine-plugin/`, `quarkus-extension/`, `spring-boot-starter/` and `wildfly/`.

For someone evaluating a workflow engine, that list is a map of the surface you will have to learn, and the samples tell you how much of it there is. A team that needs one thing, such as calling a REST service from a service task, can find it in a directory and stop reading. A team building a full platform inherits all of it, and the repository is a decent way to estimate the size of that job before committing to the engine.

The README also points out that the invoice example contained in the platform distribution lives in the camunda-bpm-platform repository rather than here, so even the flagship sample is spread across two repositories.

The version table is the real interface

The top of the README is a table mapping Camunda versions to branches, tags and checkout commands, and it runs from the current release back through 7.24, 7.23, 7.22, 7.21 and continues down to 7.1. The sources on the master branch work with the current Camunda release, and the documentation instructs you to use the checkout commands to reach the sources for the version you use.

git checkout master
git checkout 7.24
git checkout 7.23

Every versioned entry in that table is a git tag, so the versioning model is transparent. There is no artifact repository to configure. A reader on Camunda 7.19 checks out the 7.19 tag and reads code that was written against that engine, which removes the single most common failure mode in example code, where the sample has drifted to a newer API than the reader has installed.

The cost is a wide surface for a clone. A full clone pulls every version's history, and the tags are the only thing that keeps them apart. For a single example, a shallow clone of one tag is the practical approach, and for a team that wants to diff two engine versions, the tags make that diff straightforward.

One caveat: the table is a manual list in a README, so a very old engine version that predates the earliest tag simply has no example here. The repository does not claim to cover every historical release.

The service task examples split by invocation style

The `servicetask/` directory is the most useful starting point because calling out to a system is what most workflow projects need on day one, and the examples divide by the mechanism rather than by the external system.

The overview table lists a service task calling a REST endpoint with the keywords Rest Scripting and classless, a service task calling SOAP over HTTP, a variant that uses CXF with Spring and Spin, a synchronous service invocation described as a Java delegate, and an asynchronous one described with Signal and Async. The container column tells you how each one is exercised: several are marked Unit Test, which means the example is verified through a test rather than a full server, while user task examples are marked All, meaning they run in every container.

That container column is the piece of metadata most worth reading before you copy anything. An example marked Unit Test has been written to be verified in isolation, and the code it shows is the minimum needed to make the engine call your service. An example marked All is expected to work in a running platform, which usually means it needs a server, a deployment and a user in the right group.

The asynchronous example is worth a closer look as a pattern, because a service invocation that returns immediately and later signals the process is the correct shape for any external work that takes minutes rather than milliseconds, and the Signal and Async keywords tell you which engine features it leans on.

User tasks bring forms, email and the cockpit surface

The `usertask/` directory covers the human side of the engine, and the two examples visible in the overview are telling. One is user task assignment with email, and one is a user task with an embedded HTML form. Both are marked with the Usertask keyword, and the email one additionally carries the Email keyword.

These two examples cover the decisions that dominate a human workflow project: where the task appears, how the assignee is chosen, and how the person interacts with it. Assignment by email is a convenience that requires mail infrastructure and a matching user, and an embedded form is a browser form rendered by the engine rather than by your own application. The second approach removes a frontend deliverable from the project, which for many teams is the deciding factor.

The `cockpit/` and `tasklist/` directories are separate top-level entries, because Camunda ships two web applications for the human side and they are not interchangeable. Cockpit is the administration and monitoring surface, Tasklist is the work item list. The repository treats them as separate example sets, which is the right instinct: a project that needs task assignment in a custom portal will use the task API rather than embedding Tasklist.

The `multi-tenancy/` directory covers the case where one engine instance serves several organisations, and the `migration/` directory covers moving running process instances between versions, which is the operation that matters when you want to change a process definition that already has live instances.

Scripting, Spin, DMN and the model APIs sit beside the process examples

Beyond tasks and service calls, the repository covers the parts of the platform that are frequently underestimated in a first project.

`scripttask/` holds examples of script tasks, where business logic runs inline in the engine as a script rather than as Java. `spin/` covers Spin, the plugin that lets a process validate XML and JSON payloads inside a transformation step. `dmn-engine/` holds decision model examples, and the decisions covered by DMN are the kind that change often and are painful to hardcode, such as a routing or eligibility rule. `bpmn-model-api/` and `cmmn-model-api/` show the model APIs, which is how you build or modify process definitions programmatically rather than shipping a BPMN file.

`startevent/` covers the start events, which sounds trivial and is not: message, timer and conditional start events determine how work enters the engine in the first place.

The CMMN examples are the unusual entry. CMMN 1.1 is the case management model, designed for work that does not follow a fixed path, and it is the one part of the platform a team usually meets only when a simple process proves too rigid. Having a working example set in the same repository is a genuine convenience, since CMMN is otherwise poorly documented outside the vendor's own site.

Taken together these directories describe the platform's real breadth. That breadth is the argument for and against adopting the engine: you get decision modelling, script tasks, case management and model APIs out of the box, and you also accept a platform with more concepts than a typical service needs.

The runtime flavours are separate example sets

Camunda can be embedded in several ways, and this repository gives each of them its own directory, which is a good sign that the differences are real rather than cosmetic.

`spring-boot-starter/` holds examples for the Spring Boot integration, `quarkus-extension/` for the Quarkus extension, and `wildfly/` for the WildFly distribution. The `clients/` directory covers the different client libraries, and the overview list includes a section for the external task client, with separate entries for the plain external task client, its Spring variant and its Spring Boot variant. `sdk-js/` covers the JavaScript SDK, and `process-engine-plugin/` covers writing a plugin against the engine itself.

The external task client examples deserve attention because they show a different execution model. With an external task client, your own application polls for work and performs it, so the engine holds the process state and your service holds the logic, communicating through the engine's task protocol. That is the pattern teams reach for when they want the engine to orchestrate without the engine running the business code in-process.

`deployment/` covers deploying the platform, and `testing/` covers testing processes. The `authentication/` directory covers authentication, and `internal/` holds shared internal code for the examples themselves. The `pom.xml` at the root ties the build together, so a full build of the repository is possible even though the point of it is rarely to run everything at once.

Licence, tags and the maintenance picture

The repository is licensed under Apache-2.0, with a NOTICE file alongside the LICENSE, which is the customary pairing for a collection of example code that people copy into their own projects. The practical reading is that you can take an example, adapt it, and use it in a commercial system without attribution obligations beyond retaining the notice, and that you do not need to open source the result. The vendor name and the product name appearing in the example code and comments are a separate matter, and trademark rules are not something a README settles.

The maintenance picture is versioned rather than continuous, which is the correct model for this kind of repository but needs stating plainly. The release tags go 7.22, 7.23 and 7.24, with 7.24 dated 2025-10-14, 7.23 on 2025-04-07 and 7.22 on 2025-01-07 as recorded in the tag list. The last push to the repository was on 2026-08-28, and the repository is not archived. The master branch follows the current Camunda release, and a new example appears there when a new platform version ships.

The cost of that model falls on readers rather than maintainers. You get a maintained master and a frozen tag for your version, and you accept that an example for an old engine will never be updated, which is exactly right. The other cost is that the tag list is a long tail. If your organisation sits on a platform version older than 7.1, this repository has nothing for you, and the master branch will not run on it.

Editorial conclusion

Adopt this repository as a lookup table rather than a codebase. Clone it, check out the tag matching your Camunda Platform version, and copy the single example that solves your problem, such as a service task invocation or a user task form. Do not expect a framework, a shared library or a build you can adopt wholesale, because this is a set of independent samples with no published artifact. Verify first that the directory you need exists on the tag for your engine version, that the container listed in its table, Unit Test or All, matches the runtime you will deploy to, and that the Java and Spring or Quarkus versions in the example match the platform you already maintain.

Frequently asked questions

Official sources

1. camunda/camunda-bpm-examples on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases