Camunda Reviews

I'm the Leader of the Center of Excellence at my company with 18 years of experience in BPM platforms, and my team works with Camunda on several different projects where we deploy Camunda either on-premises at our clients' sites or through the cloud.

Our clients that are using Camunda range from a large enterprise media company in Brazil to banks and central industry (e.g. energy industry). We have found it to be very useful in multiple segments of any enterprise. We now have about 1,000 users of Camunda in all.

I love that Camunda is a very developer-friendly platform, and my customers have evaluated the pricing as reasonable. Personally, I also like that the Camunda platform as a whole helps us to easily measure the life cycle of all the relevant processes. For example, the Camunda platform includes Cawemo for business analysts, Cockpit for process engine configuration, and modeling tools for developers. Then you have Optimize, which is helpful in managing processes and continuously improving on them.

We haven't run into many problems, because Camunda provides everything we need to delegate solutions for all the technologies (for example, Java clusters) and programming languages that we use. However, I do think that Camunda can try to do better when it comes to solving the complexities of all the products in its software stack.

I have been using Camunda for eight years.

Camunda is very reliable but you need to understand the process engineer execution in order to provide solutions that are synchronized and, thus, stable.

It's a very scalable platform in my experience. 

The Camunda installation is very simple. For example, if your project requires standalone applications, Camunda can provide the necessary external components to complete the installation. The setup can be a little more complex when compared with other applications such as JBoss, but overall it only needs a few extra configuration steps.

The evaluation of my customers on pricing is that it is reasonable.

I feel that the Camunda engine is a very scalable platform, and compares well with many other BPM platforms that I work with.

I would rate Camunda a ten out of ten.

We have implemented it for an existing production application called Click End Connect, which is used for Orange Shops. Click End Connect allows users to view available mobile devices, select the shop that best suits their needs, and collect the chosen device within two hours without having to wait in the shop. The application handles stock verification and ticket collection processes seamlessly.

We have the Camunda Platform's cockpit, which is a key component of the Camunda Platform. By utilizing the Camunda cockpit, we can define stages and collect valuable data, including key performance indicators (KPIs). This allows us to identify areas of weakness that can be improved upon. 

The BPM (Business Process Management) cycle follows a pattern of collecting data, making improvements, executing processes, and then continuously refining them with the input of the entire team. The Camunda cockpit serves as a powerful tool provided within Camunda Platform. It acts as a dashboard, offering all the necessary information and key performance indicators required for effective monitoring and decision-making.

The most important thing about Camunda is that it's open source. It's a tool that is tuned to our pro profile concept, which suits our preferences and project needs. It's been really beneficial for us. 

The connectors available on Camunda Platform have responded to all our requirements, such as sending emails, and SMS, making web service calls, API integration, and handling show requests. 

Additionally, we were able to connect it with the Docker platform, allowing us to use containers that meet our performance needs. 

There is something that could be improved, particularly the availability of a drag-and-drop front-end tool for the workflow designer. When building interfaces, there are limited tools to work with, especially when dealing with different types of tasks, such as user tasks and system tasks. It would be beneficial to have something like the latest version of Ondula, which offers more flexibility and ease of use.

I've been using Camunda for five years now. We collaborated with a company called Schema in Paris, which provided us with support when needed and integrated closely with us. Camunda was the first product we put into production, and it has been quite successful.

We are currently using the seventh version of Camunda. We haven't upgraded to the eighth version yet. However, we are studying the possibility of migrating to the new version, especially the cloud-based variant with DB platform integration, among other features.

It is a stable solution if you have a properly configured server, regardless of the server type you are using (e.g., Apache, Nginx, or others), Camunda remains stable. 

As long as you have a good configuration, you shouldn't face any significant problems.

It is a scalable solution. We use four containers for our production environment. It is scalable and easy to maintain. 

We haven't encountered any problems with scalability during both the testing and deployment phases.

It is not overly complex to set up and implement if you are already a Java developer. For Java developers, it is quite straightforward and manageable. 

However, if you are, for example, a PHP developer or someone working with a different technology stack without Java skills, it may be a bit challenging to get started with Camunda. In such cases, I would recommend seeking assistance or guidance.

Camunda is a highly documented platform. I really appreciate that aspect. When I started working with Camunda, I made sure to read all the documentation for the APIs and other related information. It's a well-documented tool.

The deployment process utilizes DevOps practices. We make use of tools like Docker, which are suitable for various platforms and easy to use.

The deployment usually takes around five minutes. This includes steps such as packaging, configuring the environment, installing the application, and allowing the server to start. The entire procedure is completed within five minutes.

Moreover, it can be managed by a single engineer or developer who has experience with CI/CD, DevOps platforms, Docker, and related technologies. 

Although not a junior developer, one knowledgeable person can handle the deployment process. In our case, we had one individual who handled the deployment for us, and for subsequent applications, each of us was responsible for maintaining our own application.

There were some features that were only available in the paid version, not in the community version we used. For instance, we implemented an interface ourselves to view the history of our process instances because the historical data functionality was not accessible.

It is available, but it is part of the enterprise edition, which requires a paid license. We didn't have the option to purchase licenses as we migrated to open-source tools. 

So we had to customize our interfaces and tools using the Camunda API to replace the functionality found in the enterprise edition. That's how we managed it.

We have compared Camunda with the Bonita platform, and Camunda came out as the preferred choice in terms of features and functionality.

I recommend developing their expertise and skills with BPM. They should have a deep understanding of architecture. Starting with good releases is important because it allows users to become familiar with powerful tools and solutions. 

If you encounter a real problem, it is crucial to have a well-configured environment, whether it's a web server or any other production platform. Implementing BPM with good practices and optimization is key. 

Overall, Camunda can be a powerful tool to work with when used in an optimized and well-implemented manner.

Overall, I would rate Camunda Platform an eight out of ten. 

We are currently concentrating majorly on our clients in telecommunication. We are also working with new and existing federal clients and proposing Camunda Platform to them.

We are using its latest version. We are currently in the development phase. It is in our local environment, but we are planning to be cloud-based. Going forward, we will create a Jenkins Pipeline and deploy it onto the Azure cloud.

It is open-source. It supports microservice orchestration. This is what we are really interested in. We can customize our products depending on the use cases.

They have a migration plugin that can be used to migrate from one BPM to another BPM. It is in the beta stage since last year. If they can make it available in the market, it would be great. We are going to have a couple of migration projects for migrating from IBM BPM to Camunda, and this plugin would be useful. I have already discussed this with them two weeks ago and asked them to look into this and add it as a feature. We are expecting this plugin to be available in the next version. This is the only requirement we have at present. They keep on coming up with different features, which is helping us a lot. Its latest release that came out last month was awesome.

I have been using this solution for five years.

It is stable. I didn't face any issues in the production or development phase.

I have interacted with their technical support, and they are very helpful. When I have to work on any POC, I also directly work with the product team.

Its initial setup is straightforward.

I would advise others to verify the technology stack that they already have in place. They should check the orchestration part and see if they need to take care of any redesigning.

I would rate Camunda Platform a nine out of ten.

We have multiple B2B services running for our customers. We have approximately 120 workflows and are eventually migrating everything to the Camunda Platform. We have approximately 25 workflows on Camunda currently running.

The headless nature of the Camunda Platform is something that has helped us to build our own logic and platforms on it.

The cockpit features of the Camunda Platform can be improved to make it a bit more user-friendly, in terms of providing a bit more user experience for non-technical users. There could be some additional documentation added.

I have been using the Camunda Platform for approximately one year.

I would rate the stability of the Camunda Platform an eight out of ten.

There are some improvements needed.

The solution is scalable, it can fit any size business.

The technical support is good. However, the agent is not in the position to understand our use case for them to report to us on time. The speed and training of the support agents could improve.

I rate the support of the Camunda Platform a seven out of ten.

I have used K2 and some other workflow solutions previously.

The initial installation was not difficult for us because we had already some experience with the solution.

The price of the solution is reasonable. 

My advice is you have to be a bit optimistic and you need to see if this solution is the right fit. You have to determine if you are looking for a low-code platform or a headless platform. There is a misunderstanding between multiple products and the Camunda Platform being a headless BPMN, it is not a low-code platform.

I rate Camunda Platform an eight out of ten.

We use it for the public sector. Currently, we are only modeling the processes, but in the future, we would be automating all the processes. We are at the first phase of the process.

It is simple to use. The user experience is very good.

In terms of features, it meets my needs, but I would like Camunda to have an office in Brazil and provide training in Portuguese. They should provide regional support and training courses in Portuguese.

We have been using this solution for a year and a half.

It is very stable.

It is scalable for what we need. We have five people who are using this platform, and we plan to increase its usage. We are implementing it in some of the remote offices, and we would be able to expand it next year.

We are using the community version, so we are not using their support.

It was very simple. We are using the web solution, and it was very easy and quick. We could start using it in one week.

We are using the community version. There is no licensing cost.

We are beginning to use it for modeling some areas in the public sector, and there is no problem. I am yet to use all the features that Camunda has. For me, it is a complete solution at this time.

I would rate it an eight out of 10.

We use Camunda for the automation of the workflow and business process designer. We use the module cockpit and the workflow engine to orchestrate the process. We are a consulting company and we're not doing this for internal purposes. We mostly do this for projects, and these projects are for our clients.

The environment where we work is very dynamic and is changing a lot. So based on the circumstances, we mostly work on the delivery parts, as in project deliveries. At the beginning of the year, we have a clear scope, clear targets, but down the road, we face a lot of challenges where we face many dependencies. We need to constantly go around the dependencies and change things back and forth.

We have a lot of experience in the development, on the ERP, and so forth. We have seen that investing in a tool like Camunda is valuable, especially because it's an open-source product. When you do the customization, you'll be enriching and increasing the automation possibility of the product. So, the value is always increasing.

The best feature is the automation.

Camunda supports microservices and you can do multiple things. The most important thing is that you can reuse components that you have within the product. For example, let's say that I developed a workflow for a quality review; that is a workflow that can be reused in any new process. I can just ship it, plug-and-play, copy it, and reuse all of the features and components that are there. It means that I won't be spending too much time in terms of development to put it in place. To me, that is the most valuable thing about the product.

The only drawback is the time that it takes to have a complete set of workflows implemented on the Camunda platform. This is from drawing the modeling and the workflow up to the production release.

The support definitely has to be improved.

Second, it needs to be more intuitive. As it is now, to develop an automated process in Camunda, you would need to involve a front end developer, backend developer, and sometimes, someone who has experience with modeling. Where in Appian and Pega, you would be able to simply reduce these overheads by creating the process, the flow, and converting it within certain boundaries into the automated process.

The visualization part can definitely be improved. You can see the process moving live, but if you have a complex design where you would like to show the process in a different shape, that takes a lot of customization and a lot of coding effort to put this in place. The visualization needs not a little or a medium amount of work, but rather, it requires a lot of improvement. At the end of the day, we have the process, we have the workflow, we have the event, we have everything. However, what the people see at the end of the day is what they believe. So sometimes we know that we do have a lot of data and a lot of information, but we fail to represent this information in a way that meets or addresses the business requirements. Better visualization capabilities would help in this regard.

I have been working with Camunda BPM for almost two years.

I would say that it is stable, at least up to a certain extent. Whenever there is an update to the product available, we go ahead and update it to the latest.

This is a scalable platform. We have about 600 users and about 20 superusers. The superusers are developers, admins, and process engineers. They are a mix of process, business support, mobile app developers, and so forth.

Support is an area that is in need of improvement.

First, they don't have a strong knowledge center. If there is a challenge or there is an issue and you would like to look around, it's not straightforward. Their knowledge center does not address most of the challenges that a person who goes through the cycle from scratch. In building the process and building the products and building the workflow, a person will go through a painful process if they don't have enough experience.

When I say enough experience, I mean a minimum of 16 to 18 months. If someone doesn't have this experience on Camunda, it will be difficult and they will suffer to get things up to speed. The learning curve is too high, so they can do more if they enrich their knowledge center.

The second problem is that the support services from Camunda are not straightforward. When we communicate with them, they have to evaluate you. Sometimes they charge you per workflow, but there is no standard model. It is difficult for us because we have an agreement with the client that at the beginning of that project, we put in our estimation as to the required resources in terms of the infrastructure resources, and in terms of logistic resources, and support. With Camunda, because of the undefined or non-standard costing, that becomes a challenge.

So sometimes we go to a client and we see that the support costs will be much higher than the benefit of the digitalization. That's an example where we decide to do only the modeling for that client using Camunda and the classic workflow development will take place. This is the case, especially for small and medium businesses. For enterprise clients, definitely, we always go with full-fledged support.

I have limited experience with Appian and Pega BPM, but my most in-depth experience is with Camunda BPM. We did a pilot project with Appian for one or two months and we did one with Pega for about one month.

During our evaluation, we have seen that there are pros and cons to all of them.

We also used K2 as one of the platforms, as well as Microsoft BPM. The Microsoft product was a combination between Dynamics and SharePoint and so forth, it was really rigid. Similarly, K2 has a lot of limitations.

This is important because once we get the business requirements, we adapt to the system. We don't force the business to change, especially in this region. We are in the Middle East, Gulf area, and working with the government sector means that they have their own standards that we need to comply with. They have their own procedures where the tools, the IT, and the process have to be adjusted to meet their requirements. For example, consider a supply chain and the procurement process. This is different from one organization to another.

This is the main thing that holds us back from investing in a system like Pega. Pega, to a certain extent, is good. It has most of the capabilities. It also gives you the room to customize to the extent that you feel fit. However, the cost is too high. When we talk about the licensing costs and the customization costs, it's extremely expensive and out of reach.

The initial setup was not straightforward. The complex part was to load or update the backlogged events. So if I have a process, which is already past the flow to a certain stage, after the implementation, if I did not start from scratch, you would need to make the data or the workflow that you have current with the process. Making it current with the live process monitoring is a nightmare. It takes a lot of development effort, a lot of data validation, and a lot of workarounds to bring this up to speed.

I have not seen that there is too much support in being able to bring in existing services. For example, if someone has an existing process, an existing instance with existing data, which is not linked, there is no explanation of what the best approach is and how to load and how to bring this into the new process and make it current, covering the backlog.

This is especially true if the backlog is something that would be crucial for some of the processes that are down-line. For example, in the case where you have a successor process where it depends on the predecessor too much in terms of the decision, and also in terms of that project. Normally, we deal with delivery on projects, so we look at the delivery and the forecast and the delays. So to see the project delays, sometimes we need to go back in time to see whether the delay was in the first stage or on the second stage or on the third stage. Based on this analysis, we always create our baseline by the end of the year and reiterate on our scopes at the beginning of the year.

We have an in-house team of two resources that maintain the product.

The cost of this solution is better than some competing products.

My advice for anybody who is considering Camunda BPM is that they implementing a PoC first.

I would rate this solution a six out of ten.

We like the BPMN notation because it's BPMN 2.0 compliant. We like the out-of-the-box REST API features so we can build a service with Camunda, and instantly it's accessible using a REST interface, and of course, we like the REST protocol because that's much more advanced than SOAP.

The other feature that's highly advertised is the fact it's open source. We have the ability to modify the product if we need to, and that comes in handy whenever we need to add new functionality and features. One popular one is a year-end mapping feature, which is basically mapping a bunch of URLs to label in the tool, which the services can access. Instead of having to hard-code URLs, you can get the service to use the label. That is, you can configure the label in the administrator. That doesn't come with Camunda, but you can build it yourself.

The open source factor is a big one because we don't worry about feature customization issues. The problem with proprietary products is, if they're not giving you the features you want there's nothing you can do about it. All you can do is ask them to change it, and usually the product vendor is not interested. Even though you're a big client, it doesn't matter. They're worried about many clients, not just one client. So open source is huge.

Another one is that it's quite lightweight. It's much more lightweight than most other tools, so it's easy to code in, and we don't really have performance issues.

Third, using REST APIs out of the box really improves our productivity. You build it it, you deploy it, it's ready, it's good to go.

Like all BPM tools, they're very bad with proprietary UIs. In general, anyone who uses BPM tools should not expect to use their proprietary UI. It just works awfully. It's very difficult to customize. You should just build your own UI and have the UI call the REST services of the BPM service.

I've seen many mistakes made by many users of BPM tools where they just use the whole thing for everything. They use the BPM tool for the service, and then they use the proprietary UI for the UI. Next thing you know, whenever they want to customize the UI, they can't do it, or whenever there's a tool upgrade, it impacts their UI. It's just a big mess, and it gets expensive. Camunda could do an upgrade, and suddenly the UI has got a problem, so they have to spend all these man-hours to fix their UI and convert it.

Whereas, if you had a loosely coupled system where the UI is separated, where you just build it with AngularJS or something like that, then you don't care.

My team started using it in 2015, so we're going on about 30 months now in app years.

It's very stable. We've run load tests, and the only problem you'll have with Camunda is, sometimes, when you marry it with other technology like MariaDB, and you put it under high load, it seizes up. Then, when you go to the Camunda people, they say, "Well, what we're building is a tool. We didn't design Camunda to work with every little, specific product." But you'll find that issue with many BPM tools.

It's very scalable.

The only time we have a scalability problem is when the application team doesn't use it properly. For example, I've seen many BPM build teams, they didn't set up a separate database for their application data. They just used the schema that's supporting the tool engine. When they do that, the more you load up the database schema that supports the tool, sooner or later, the tool starts to bog down on server startup. Instead, they need to put all their application data in a separate database.

They're quite accommodating. I've even seen their offices in Berlin, and they're quite accommodating. They definitely go above and beyond to help you out. But at the end of the day, they're going to draw a line somewhere which is usually, "This is a proprietary UI. There's only so much we'll do for you. If you're trying to integrate this with a certain product, well, we never designed Camunda to integrate with this product."

They'll draw the line some, but it's typical for all teams, all tools.

ActiveVOS, but it is not open source. That's one of the reasons we switched.

At Camunda they had a subscription service. It was based on how many flow nodes, I think 4 billion flow nodes, and they would give you a one-time fee. You just had to pay it, and you got internal support.

Of course, you can use them without their support. You can just download it and use it, but any self-respecting entity will get support. Where they make money is not licensing. They get it in support because, sooner or later, you want help.

They have various subscription models. One of them is pay a one-time cost, and they'll support you.

We evaluated ActiveVOS and, in the past, we've looked at IBM BPM.

In terms of advice, if you're considering Camunda, you must know how to code Java. If you go on YouTube and type "Camunda", or "intro video for Camunda", the Camunda people will tell you, "You need Java developers."

When you go open source, you start to make the product a little more complex to use because they don't have as many wizards, whereas, some people will get away with only knowing scripting. They were able to use ActiveVOS because they've provided a bunch of wizards. You need Java developers to use Camunda properly.

Overall, it's very flexible and nimble.

We use the BPMN flows for order capturing of our end-to-end customer journey. There are many intermediate flows and we mainly use the tax delegate part of it.

We have been able to save costs using this solution compared to the product we used before.

I have faced problems in bringing up the Cockpit in terms of GUI processes. I think that there is room for improvement in those areas.

We have used this solution for one year. 

This is a stable solution. 

We have a support contract this has been working fine for us till now.

We previously used a product from Ericsson. 

The initial setup is a bit complex.

The learning curve is a bit steep. I would rate this solution an eight out of ten.