Using our Best Practices

Camunda's Best Practices represent our Consulting Team's condensed practical project experience for using BPMN and DMN on the Camunda Platform.
Using our Best Practices

What is a Best Practice all about?

Our "Best Practices" have been developed following issues or concerns as they typically arise in our customer’s projects when implementing the BPMN or DMN standards and automating them by using the Camunda Platform.

You will notice this practical, real-life, project oriented approach when reading titles such as Using a Greenfield Stack, Testing Process Definitions and Creating Readable Process Models.

real life

Each of these links lead you to documents condensing years of our Consulting Team’s real-life project experience into a Camunda Best Practice. Each of them designed to save you from making common mistakes others have made before you - as well as being enjoyable pieces to read and study, of course! :-)

Providing us with Feedback for our Best Practices

You are very welcome to provide us with feedback and join a conversation with us about the content of our best practices. Please just write an e-Mail using and our Consulting Team will get in touch with you!

Finding the Best Practices Most Relevant For You

The main index page of our best practices collection sorts the documents for stakeholders, by keywords and following the customer success path. Just select one of the tabs shown there, when searching for a specific document:

index page tabs

For Stakeholders

The first tab of the main index page of our best practices collection sorts the documents for the typical project stakeholders, like "Architecture", "Development", "Modeling", "Operations" and "(Project) Management".

Documents may be referenced multiple times - for different stakeholders.

By Keywords

Sometimes you might have a certain keyword in mind, and you might want to find the associated best practice. For instance, you could be looking for advice around task lists then you might want to scan the second tab of the main index page and will be able to find those best practices which have information relevant to tasklists.

Documents may be referenced multiple times - for different stakeholders.

Following the Customer Success Path

The customer success path represents the most relevant Best Practices in the various activities you will typically face when doing your first BPM project. Click on the third tab of the main index page and see those best practices in a meaningfully sorted order. Alternatively check out the document Following the Customer Success Path written to gently guide you through those documents.

Understanding the Structure of our Best Practices

Each best practice starts with a table of contents listing its sections. Note that you sometimes find additional tabs next to the 'Table of Contents'. These tabs will point you to the wider context of the best practice. To give you an example, the following tabs show the table of contents of Using the Camunda Tasklist …​


will indicate that you might want to learn All About Tasklists, that this best practice is part of the Customer Success Path guiding you through the most important Best Practices when doing your first BPM project and that it has Related Best Practices, meaning that they are related on the basis of shared keywords.

Best Practice Documents and their Sections

Each best practice is written as a single document, all of which are accessible online at by using your Camunda enterprise customer credentials.

Each document starts with an essentials paragraph which is marked with a light-bulb icon. It is intended to roughly inform you about the content of the document and sometimes about the most important recommendations contained in it. The rest of the document typically consists of several sections listed in the table of contents prominently displayed at the beginning of each Best Practice.

Note that a click on the Camunda logo in the upper left corner of each document brings you back to the main index page of our Best Practices collection.

Special Bonus  Sections

Some sections are marked to be Bonus  which means that they are not part of the best practice in the narrow sense. They represent a bundle of looser, additional information intended to help you in some respect, for example to get you started by showing you examples or collecting related information or links.

Assisting your Decision Making Process with Tables

Rather than just stating a single "best" approach, sometimes we decide that it makes more sense to assist you in making your own, situation specific decision making process (thats what consultants do, and why the answer to most questions is "It depends!"). We then represent you with possibilities and probable decisions drivers in the form of a "decision making table". An example of this kind of table is shown here to give you a better idea of what we mean - see the full table in Deciding About Your Tasklist:

decision making tables
  1. The columns of this decision making table represent your possibilities. When developing a tasklist for your own process application. You can either just go for the Camunda Tasklist, or you can opt to develop your own Custom Tasklist/Application or you could also be inclined to re-use some existing Third Party Tasklist application.

  2. The following rows of the decision making table represent the drivers for your decision making. So in this example you can see, when using Camunda tasklist, you will face a lower development effort when compared to building your own custom tasklist/application. While both of those options offer extensive customization possibilities, the influence on user acceptance might be decisive in your specific case - or not. This is just an example helping you to interpret the structure of a decision making table like the one shown above.

  3. The last row typically contains links leading you to even more information about the respective option. In our example - If you’ve decided to go for Camunda Tasklist, you might want to learn much more about our Best Practices to use and adapt it.

Marking a Possibility or Option as Our GREENFIELD Choice

Sometimes you will notice our GREENFIELD badge. This indicates that the discussed possibility or option would be our subjective choice when having to select something for a "greenfield project" without facing contradictory requirements driving us in another direction. For example when selecting a technology stack for a new project, you might want to use our greenfield stack.

When We Think You Must, Should, or May Follow Us

In some cases, we decided it’s a good idea to make you aware of the importance of certain aspects of a best practice by marking them as Must haves, Should haves or May haves. See e.g. our guidelines for Naming BPMN Elements for an example of that.

  1. means that in our opinion, you MUST comply with the presented practice.

  2. means that you probably SHOULD follow the practice, but may know exactly why you do things differently in your context.

  3. means that you MAY want to follow our suggestion, because it proves to be useful under most circumstances.

Providing you with Background Information

Sometimes you will note paragraphs marked with an info icon. These sections intend to provide you with additional, sometimes more circumstantial information or background information regarding our reasoning for the best practice. In case you just want to quickly "scan" the most important aspects of the document, you can decide to ignore those sections.

Warning You About Certain Dangers

Illustrating Anti Patterns

Sometimes you will notice examples clearly marked with a "thumbs down" icon. This will indicate that the shown example illustrates how things should NOT be done - we like to call such examples "anti patterns" or "bad practices".

When comparing such "bad practice" examples with positive "best practices" we also show sometimes the "thumbs up" icon.


Sometimes you will notice a section, table cell or paragraph marked with an INTERNALAPI badge. This will indicate that the described way to achieve things uses purely internal and therefore unsupported API’s of Camunda. While the usage of such internal API’s might sometimes give you access to powerful mechanisms, you also need to be aware that they are less future safe, as the methods might change from Camunda version to version without prior notice.

Facing Other Dangers

Although occurring less frequently than other symbols, you will occasionally see a paragraphs marked with a danger icon. Well, when working with BPMN and DMN on the Camunda Platform, there certainly are sometimes things you want to really avoid. Typically you do not want to miss exactly those "Don’ts" when doing something in the discussed area!

Understanding the Applicability of our Best Practices

Relevance of Best Practices for Specific Roles and Stakeholders

The main index page of our best practices collection sorts the documents for our typical project roles or stakeholders, as "Architecture", "Development", "Modeling", "Operations" and "(Project) Management".

A best practice document might be relevant for more than one group of stakeholders. In these cases it will show up in more than one stakeholder section of our main index page.

Taking Into Account the Wider Topic of a Best Practice

Some best practices are just applicable under the assumption that you already have taken certain decisions and are therefore already going down a specific route. We bundle such best practices into topics marked with an icon. In case a certain best practice is part of a topic, you will see one or more special tabs next to the Table of Contents:


So, assuming you stumble upon Using the Camunda Tasklist you will notice that this is part of the wider topic called Tasklists. When checking out the topic, you will notice that the first document of the topic deals with Deciding About Your Tasklist. Once you have reviewed that document, you will better appreciate the implications of Using the Camunda Tasklist for your own project.

Printing a Best Practice

Best Practice documents are printable!

Just use the printing function of the browser of your choice - but note that we currently can only guarantee a certain degree of quality from Mozilla’s Firefox, Google’s Chrome and Apple’s Safari browsers. Of course, you can print with Microsoft’s Internet Explorer, too, but you will probably experience a few formatting issues when doing that.

We put quite a bit of effort into the possibility of printing a Best Practice document in an easily consumable format. We optimize - for example - the right size for the BPMN models shown, list the links pointing to external web resources in a special footnotes section and take care of many other small "nasty details".

Whatever you do, try to be consistent!

You might decide to not follow a best practice if you have good reasons to do so. Our experience says: Whatever you decide to be the "best" approach for your own issue at hand and under your own specific circumstances, we recommend that you try to be consistent in what you are doing. We reason that a commitment to consistency is of high value for every project, because it helps to keep things as simple as possible and as easily transferable to new project team members as possible. It therefore helps to keep frustration, effort, and waste low. Just invest a bit into conscious decisions and shared team knowledge about those decisions every day and rest assured:

Your Camunda implementation project will be lots of fun! :-)

Scope and Limitations of Best Practices

These Best Practices represent the current state of our practical project experience as far as it is generalizable. They are neither "final" (in the sense that we ourselves will hopefully continue to learn!) nor are they necessarily the best approach for your own situation.

Note that Best Practices are not part of Camunda’s official product or product documentation. Hence we cannot give the same guarantees for them. In order to present as much experiences as possible to you, we 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.

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.