Camunda Reviews

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 Camunda Platform for automating networking business processes.

The most valuable feature of Camunda Platform is its Microservices architecture, which is easily integrable with APIs.

Camunda Platform's customer support could be improved because their response is quite slow.

I have been using Camunda Platform for approximately one year.

Camunda Platform is a stable solution. However, we recently lost a lot of data because the solution's database was down.

I rate Camunda Platform a seven to eight out of ten for stability.

The solution's initial setup is quite straightforward. I rate Camunda Platform a six or seven out of ten for the ease of its initial setup.

Camunda Platform's deployment was done in a day.

Compared to other software, Camunda Platform is quite cost-effective.

Overall, I rate Camunda Platform a seven or eight out of ten.

We use an open-source version of this product. In some cases we install on-premises, in some cases, we install on Dockers. How we install the product depends on the use cases and the needs of the projects that we engage in.  

One client may be in logistics. Another client may be involved with internal communication. Another one is in retail. Some will be in business project management. We have to treat each of these to fit their unique needs.  

I like the product since we are a Java-oriented company. Our solutions can be compact with Java. We found it quite useful because we can merge microservices together. It is a different kind of architecture but it is a flexible product that we can use to go live with solutions quickly.  

From my point of view, there is a lot that has room for improvement. But one option that they should focus on most is improving the basic parts of the BPM tools. One example is that they should offer some additional options in terms of employing connectors. We implemented most of our solutions in Java through delegation. We could have done a better job of that with connectors. So connectors are one of the cases where they might improve.  

Another point that I am thinking of that I can not do by myself is to improve the forms. Right now the forms are fairly simple. It would be nice to implement some kind of wizard, or advanced form, and be able to fill in data dynamically.  

A possible add-on is to have a mobile app. Specifically, it would be a tool used to prepare forms dynamically and to preview business projects. If you know what you need to do, you can actually do a lot with a product like that.  

From a security point of view, I think that some features can be added or enhanced. I see a lot of opportunities for interesting stuff that can be implemented like installation identity or places where token authorization can be used. More security measures can be added in order to offer options to protect the front line.  

One final feature that would be nice is the opportunity to operate an active database. I do not think that will happen soon. It is okay because we have very powerful database options right now.  

We have been using this solution for about one year.  

The stability of the product is quite good. You need to have the knowhow to work with it to optimize for best performance with the database and CPU and stuff. But it is a stable and reliable product.  

It is a scalable product. We do not have much on the cloud right now. It is less than 5 nodes. But we could expand that if we needed to.  

As I understand more of the benefits of using the product, I have more plans to increase usage. With any new customer that has a proper use case, Camunda will be my first choice. Even if it is just for the fact that we know we can deploy fast. We can start with a single instance and after that, we can scale without hesitating too much in the planning stages. It is very comfortable for the customer to see things happen quickly. From our experience, most new customers prefer to start small. Better to start fast and get them going and to build them a little at a time to more automated projects than to wait around with nothing seeming to happen.  

I have been around 10 years or more in this industry as a solution architect. With this product, we have the flexibility and speed to serve customers quickly and that is important.  

As for technical support, let's say we do not need it. We can cover any issues by ourselves with our team. We do not have any issues. If we do have an issue, we will compensate for it using Java.  

I prefer not to mention the other product by name because it seems like I would be saying it was not good enough and had to move on, but we did use a product as a solution before Camunda. Every product has its benefit in terms of what they deliver and we just decided that Camuda BPM fit our needs better than the other solution.  

For example, if we wanted to incorporate a solution in a situation where a client was using the Oracle family of products already, we might use Oracle SOA or Oracle OSB to stay within the family of products. Those choices would be a perfect fit.  

On the other hand, if your stack is Spring Boots and Java and open source, Camunda fits well. If you are stuck in an enterprise using Red Hat, there is Bonita and other Red Hat BPMs that may work best for you.  

What you use depends on a lot of things. It could change because of the recommendations of team members, it might depend on the current environment, it could be influenced by whether the company is new and needs to grow fast or if it is an established company with a predictable trajectory. At the end of the day what you use depends on the choice you make for what best fits your circumstance.  

The setup was straightforward. We need to have Java, and that is it. My team does the work on the deployments so I don't know exactly how long it takes anymore. But it is a simple concept that the more complicated the client's needs and use cases are, the longer it will take.  

We do deployments with just two people: one senior and one junior tech. But it depends on the complexity of the workflow. Sometimes we might bring an extra tech if the workflow is complex.  

Of course, we do not use an integrator, reseller, or consultant for the deployment because we are in that role. We know how to build it and we know how to run this kind of project. In the beginning, we did make a lot of mistakes, but at the end of the day, it works. Now when we have a new customer, we know what to do.  

We are using the open-source version so it is without cost.  

My advice about Camunda is I recommend this product when it fits your needs. It is that simple.  

On a scale from one to ten where one is the worst and ten is the best, I would rate this product as a nine because it fits my demands. Of course, there is always room for improvement in the interface, or performance, and stuff like that.  

I hope that people will work on Camunda and within the next releases we will have more connectors, we will have a much more powerful interface, and maybe we can have a mobile app as well.  

The primary use case is for modeling processes.

It allows me to present or to demonstrate the business process flow, visually, without having to resort to PowerPoint, Visio, or other products. 

I can convert it into a real process. Once it is validated visually by the business people, then it can be enhanced into a full-blown process model.

The features that I like the most are the drag and drop.

The simulation feature of this solution needs improvement. As an example, if I wanted to highlight an event then when I press on it, I would like all of the impacted processes to highlight. That way, you can see the impact of an event on different processes.

If there were some industry templates it would have helped significantly, because it is similar to a process map for a domain. That is what we are currently creating, a domain-relevant process map. 

When it comes to insurance, just to give you an example, there is marketing, then underwriting, policies for contracts, policies for prevention, collections, there are claims, and business flows that we had to create from scratch. If we could have started through a template, it would have helped us kick start the initiative.

I have been using Camunda BPM for one year.

This solution is stable. I have not experienced any issues with this solution.

It's a bit early, so I haven't stress-tested it yet for scalability.

We have three users.

I haven't reached out to technical support.

I found everything on the website. The manuals and tips were useful.

Previously, I used BPM online, but I changed to Camunda BPM because I downgraded my current requirements.

I enjoyed BPM online but needed a more lightweight tool for modeling. BPM online is cumbersome on the modeling side.

The initial setup was straightforward.

It was deployed a year ago, so I can't remember exactly, but I think that I only took a few minutes to deploy.

I did not use an integrator, I did it on my own.

It's free, open-source.

I use the open-source free version.

I reviewed Sygnavio and Pega Systems. 

I chose the Camunda BPM, because I am domain-oriented, and I saw that many companies, especially in my domain, the insurance domain, are using Camunda BPM and that gave me the insight as to where I should focus my efforts.

We are currently a startup with Insur Tech and we are sensitive to cost. It's our strategy and it is the best tool for the price at this time.

What I have learned from using Camunda BPM is to keep it simple.

I would rate this solution an eight out of ten.

One valuable feature of the solution is its flexibility. Unlike low-code platforms or those with predefined design patterns, Comunda allows for custom changes, providing the freedom to customize.

I have been working with the solution for the past six months.

The initial setup is straightforward.

I have worked with Pegasystems. Primarily, Pega operates on a case-based licensing model, where each workflow incurs charges. Many customers opt for Camunda for basic workflows and case management to save costs. However, for enterprise-level needs, especially those involving CRM functionalities, Pega is retained. Some organizations have transitioned specific workflows to Camunda while keeping Pega for comprehensive CRM solutions.

Camunda primarily functions as a BPM platform. It requires development work for customization. Users accustomed to a local setup may find it less preferable. At the same time, tech-savvy developers who enjoy extensive customization options may favor the solution due to its flexibility in adapting design models based on their preferences. For such developers, this solution would be a perfect ten.

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.