Camunda Reviews

We leverage Camunda for two different use cases in Santander Brazil. I used and we used to have an orchestration flow for processing new credit approvals. Once the customer requested a new credit on the Santander mobile app, they received the confirmation instantly, online, but asynchronously, we had several updates and documentation to prepare in order to make back-office processes complete. The customer received the instant confirmation, but we used to have a long-running process with several steps running in parallel and asynchronously, and those steps were orchestrated through Camunda. That was one use case, basically API orchestration in an asynchronous process with no human interaction.

We leveraged Camunda for the back-office processes for Santander Esfera, which is a loyalty program from Santander in Brazil. It is mainly a marketplace where customers can use loyalty points to redeem products. The order management process for that marketplace used to run through Camunda as well, leveraging APIs and in some cases, handling exceptions and human interaction.

Camunda's support for BPMN 2.0 is a great advantage because it allows us to have a common language to discuss technology and business in the same perspective. This capability used to allow us to anticipate issues and discussions with the business and product teams.

Since they are basically a fork from Activiti, which was a lightweight architecture that would allow us to run the process in a way we used to call the process API or a headless process. There was no need to deploy and run heavy and large tools and frameworks and middlewares, allowing us to embed the process engine inside our Java applications. That was another advantage, and it worked fairly well with cloud environments. The limitation they have with transactional databases that ultimately they were able to get rid of when they launched Zeebe was not really an issue for us. We did not have the scale and transaction volume that would make a need for such a high throughput environment. The standard or original Camunda deployment with a transactional database was more than enough for our use cases.

The learning curve for understanding how it works and deploying the first processes, especially for those people who have a background in Java, seemed to be a really fast-paced adoption for us. When we compared with other process automation tools such as Pega and IBM BPM, Camunda seemed a better approach for us.

I think Camunda is focusing too much on the SaaS offering right now and not much on improving and developing the product itself. I did not see any innovations on that aspect, especially for the open-source version. I was making some tests recently and the tool seemed pretty much the same as it was three or four years ago.

Since they made the move to cloud deployment in a more SaaS-oriented way, they do not invest too much in the community version. To be honest, it did not change much from the Activiti initial version. Activiti was pretty much what Camunda is today. They invested a lot on Zeebe and made it the engine for their SaaS cloud version. Camunda itself, the embedded engine, did not evolve too much. They could invest more on that.

With Camunda they have a tool called Cockpit. We measured the time for each step individually because each activity in the process was an API call to an external API in a different legacy system. We used to track the performance and other metrics on those specifically. We were not really concerned about the performance on the process itself because it was super simple, super straightforward, and it did not present itself as a bottleneck, nor did we feel it was adding additional time in the execution. For us, the process itself was fairly seamless.

Camunda integrates well. They have that REST layer, REST APIs layer that makes it easy to integrate and make it part of a microservices ecosystem and APIs. That worked pretty well. We had some specific processes that were API orchestration processes, and the starting of the process was an API call directly through the Camunda engine. It played fairly seamless with no big issues on that deployment.

The support for Camunda is great. The team is very responsive. They really understand deeply and in detailed fashion the solution. Any issue you have, they answer back right away. For the support, they made a great job. On a scale of 1 to 10, I would rate them a 10 for support.

Positive

We purchased the license for Camunda. It was not simple, and at the end of the day, it is an expensive tool. I think for enterprises, it pays itself pretty well, but for startups and teams that are trying to make some tests and understand if the tool is the best solution for their specific scenarios, the pricing model right now is a concern.

I could not even purchase a version straight from their portal. I had to contact sales and then fill out a form, a representative team in Brazil received the form but did not get in touch. It is not really self-service, and I would prefer to have something where you can just put your credit card and use the tool as you want. That lack of transparency is an issue for us right now.

When we compared Camunda to other options for running back-office processes at Santander Brazil, those credit processes have very large profit margins. So any tool running on those processes would be of good return. When compared to Pega and IBM, we made the bet for the cost of development. With IBM specifically, we had the license already because we had other tools and contracts. But the development was not as straightforward, and the running infrastructure costs for running and setting up the tool was not cheap. It was more expensive than running the process embedded in our Java applications, the way we did with Camunda. For the total cost of ownership, Camunda seemed to be the best option, but it is not cheap.

I would rate Camunda a 7 out of 10. It is a great tool with great support, though licensing is not so good, and evolution-wise, they are not investing as much as they should. I do not think Zeebe is a no-brainer evolution for Camunda as the two products are very different.

Our primary use of ECS is to host all our services in the cloud. We work in the legal sector, and our workloads are often deployed on Fargate containers or Azure containers to abstract the hardware.

EC2 makes scaling horizontally incredibly easy, especially when working under the ECS service. Nowadays, I almost never need to create instances of virtual machines because most workloads can be deployed on Fargate containers. This abstraction of hardware reduces the need to think about it. 

My costs are reduced. Working with ECS and Fargate doesn't require saving processing units for idle services. Previously, using EC2 required keeping entire virtual machines running, however, Fargate eliminates this cost. ECS also allows for horizontal scalability with thresholds that can be configured for CPU or memory.

There is an issue where, in some situations, I need to scale up by observing both CPU and memory usage of containers, yet under the current options available at Amazon, this is not possible. I have to choose between monitoring CPU or memory to scale my solution. Not every software is built for deployment as a container service, although the current architecture trend is changing this.

I host everything in the cloud, and I have over ten years of experience. I use EC2 as a hosting technology and have been using it for a long time.

My services running on ECS are also on Azure Container Service. I have never experienced any flicker or downtime. These are highly available services. It's very stable.

ECS and Fargate make horizontal scalability very easy. I rate the scalability a ten out of ten. It allows for easy scaling, especially with ECS service configurations.

The AWS Support is incredible. They always invite us for meetings to showcase new solutions. I have a very good relationship with AWS, Microsoft, and GCP for support. AWS provides the best support, followed by Microsoft, and then Google.

Positive

Setting up ECS is simple, although there are some tricks involved. I usually have to define private and public networks and bind all related services. It's easy but not super straightforward. I had to repeat the process two or three times before I could teach others how to configure it.

Hosting services on Fargate reduces our processing costs since we don't need to keep virtual machines running for workloads anymore. This results in cost reductions.

AWS pricing is very competitive compared to Azure and cheap compared to Google. For some services, such as hosting databases, Google is really expensive.

On a scale of one to ten, I rate ECS a ten out of ten. It's an incredible service, and I prefer it over Kubernetes. I suggest checking the integration of software for deployment in a serverless environment. Some software can be challenging to deliver this way.

We use it in telecom service management to automate and orchestrate our service order flows.

There is DMN (Decision Model and Notation) on the flows, but it depends on how the user interprets the question. If it's purely decision-making, then not really. It's a feature of the platform we use but not the main one. 

The main feature is the BPMN orchestration workflow engine.

We had to look for a replacement because our old tool didn't evolve anymore. Camunda is a further evolution or branch of activity. There are certain branches of workflow engine tools, and Camunda seems to have a lot of traction, maturity, and stability. It also matches the need for agile development. 

In terms of efficiency and execution, we're satisfied. In terms of design, you still need to create the design and give it to someone else, but the graphical user interface is fine.

The fact that it's open source is interesting. My colleagues like the support, even the free or basic support. We now have enterprise support, but they were quite satisfied with the basic one. 

The main feature is BPMN, in its totality. You have the design, editor, monitoring, execution, scaling, and deployment. So, it's the total package that they're quite happy with.

Probably one area I look forward to has to do with AI and how Camunda sees the AI angle on workflow. I know they're working on that or at least communicating about it. They already have versions to run on the cloud, so they've tackled that. We're looking at what they will come up with otherwise. 

As long as the product gets enough traction and evolves, we're happy. With open source, you can monitor what's happening. If the product is being left by many customers, that's a sign. We're also users of Camunda, and you can watch one of our guides' presentations in the States about one of our implementations.

Our focus now is on developing service management and DMN APIs for the platform. AI is something we take into consideration, but we'll see what additional benefits it could bring and how to interconnect it with our data or AI engineering.

I have been using it for three years. I use the latest version. 

I would rate the stability an eight out of ten. No major things to worry about.

I would rate the scalability as eight out of ten, and it could be improved. I am not 100% sure of its scalability capabilities. We haven't done enough volumes on it. 

The system is primarily for automated flows. Maybe there are 20 or 25 people who use the production version as a user. It's not really a system with a lot of manual stuff. For us, I would assume the usage is rather limited at this stage.

It is used in production every day. We plan to increase the use of Camunda in the future. 

We now have an enterprise contract because of the increasing volume in production. We want to ensure we have good enough SLAs, so we probably bought the enterprise support. 

Positive

We had plenty of workflow engines in that domain. The company used Oracle BPEL, a workflow product that was originally open source but was bought by Oracle a long time ago and then became a paid license product.

Other products in different domains: 

We've got SAP HR modules and logistics modules, and we've migrated a few to SAP HANA, but I'm not the best reference for that domain. 

In our multiple domains, we have a mix of commercial and technical platforms. We use Camunda for custom development, and ClickSoftware for field work management, which we're migrating to IFS.

For the setup, I'd probably rate it a nine out of ten. I'm not personally involved, but it's quite easy.

• Deployment resources: It's probably only one or two people who were busy installing the product. I don't think it's a huge problem or challenge.

• Integration aspect: There was a bit of a challenge, but it was resolved by redesigning an activity in the process flow. It wasn't a huge problem, but the people had to figure out how to use existing mechanisms to solve it.
• We can resolve the challenges that might arise in Camunda using the features on the platform. It might not be immediately out of the box, but we can find a setup or pattern that brings us the solution. We can extend the framework. I haven't really seen blocking factors at this stage, and I know of other companies that use it, so it looks alright.

• For the maintenance part, I assume it's quite a small team. 

It's a license for support. So, it's not too expensive, in my opinion.

Development teams use open source components, do a small check on different tools, and then go for one. I don't think there was a specific RFP (request for proposal) process involved, but I'm pretty sure they looked at the market. They looked at other workflow engines like Activity in previous projects.

Overall, I would rate it a nine out of ten. 

My advice:

New buyers should definitely look at this option. It's a good option as the product is technically sound. There are quite a few customers running on the platform and good reference customers. There is a community forum, and the documentation is readily available. So, if you are investigating options, it should definitely be on your list, if not at the number one spot.

Recent trends around workflow automation:

We see a lot of cloud SaaS solutions coming up with their own workflow platforms. For example, SAP or Salesforce also come with workflow systems. You need to consider that these platforms have embedded options where you have no choice but to use them. But if you have spots where you do your own development or there is a package that uses Camunda, the interesting part will be what steps they provide to work with the data and AI to make the solution even more attractive.

Camunda can be used in various workflow scenarios, such as policy administration systems, onboarding, account management in telecom, insurance products, policy issuance, claims management, and loan management. 

It is also suitable for customer service center activities where customers' accounts are created. Camunda can manage any workflow that requires customer interaction with the system. It is a competitor to other BPM solutions like Pega.

The architectural part of Camunda for workflow design is highly valuable, especially the Camunda Modeler, which allows quick process design and implementation. Camunda's DML is a competitor to the implementation of business rules. 

It integrates well with Java, making it suitable for various technology stacks. Camunda facilitates microservices integration. Its SaaS model provides scalability, automatically managing and scaling implementations.

The deployment model could be improved for easier implementation. More open documentation would be beneficial to understand the deployment process better and facilitate easier setup.

I began working with Camunda in 2013.

Camunda is quite stable, and I would rate its stability around eight to nine out of ten. There haven't been any significant outages in my experience with Camunda.

Camunda offers a high level of scalability, especially when using its SaaS model, which manages and scales implementations automatically. I would rate its scalability a ten out of ten.

Camunda's community is medium-sized, offering reasonable support. However, they provide better support for the enterprise edition. There was not a large community in the early years.

Positive

Other competing solutions include JBPM, Activiti, and Pegasystems.

The initial setup can be difficult, with a rating of seven on a scale from one to ten. While not very hard, some features present challenges.

For earlier versions, implementation involved bundling applications as WAR or EAR files using Maven, and deploying them on JBoss Server. I have yet to explore Camunda 8's implementation process.

There is a licensing cost for using the SaaS model and Enterprise edition of Camunda, although I am not aware of the specific pricing.

Other solutions evaluated include JBPM and Activiti.

For anyone considering using Camunda, it is essential to understand your workflow clearly. Camunda is the best among similar solutions like JBPM and Activiti. I love working with Camunda.

Since I completed the courses at my workplace, I have only used Camunda for testing and practice. We had assignments to create a flow for pizza delivery and another one for an electronic shop. This practice was verified by our professor.

We have one process that was migrated from our RPA department. It used a series of UI elements for client cases, but now it is streamlined using API calls in the background. The process is more stable and efficient because it processes cases faster without being affected by UI changes like new buttons or pop-ups.

The use of Java is a big plus for our intern developers, and Camunda scales well, as many of our departments are already using it in production with dedicated teams.

The setup process is a drawback as it has many dependencies, which affects our ability to migrate to Windows eleven due to security concerns. I would like to see better integration with the Microsoft suite and more language options, especially for our internal applications.

I've been using Camunda for a few months. 

I have not experienced any performance or stability issues. It runs smoothly.

Camunda is more scalable than Blue Prism. It supports entire process automation, including manual tasks, not just robotic processes.

There was no need to escalate any questions to Camunda's tech support. However, I have escalated issues for UiPath and Blueprints.

Positive

Our department used Blueprints since 2020. The transition to Camunda is challenging since people are familiar with the previous tool.

The initial setup was guided by the professor's guidelines and involved installing several programs and agreeing on a Java version. After setup approval and training, we encountered some issues that were addressed with help from the professor.

The transcript does not contain specific information about ROI.

I don't know the exact numbers behind cost-effectiveness. I know licenses for the other tools, like UiPath and Blueprints, become more costly over time since they require annual renewal.

I also have experience with other process automation solutions like Blue Prism, UiPath, Power Automate, and Blueprint.

I would recommend Camunda because Java is well-received and encourages clean code standards. The tool's visual appeal makes it accessible to both developers and business analysts. BPMN notation familiarity is a plus.

I'd rate the solution nine out fo ten.

Our common use case for Camunda is working on seeing how we can replace Bonita with it for some projects.

We are trying to replace Bonita, especially because the reporting in Camunda seems to be more developed than Bonita's tools.

The biggest difference between Camunda and Bonita might be that Camunda is simpler and more flexible for setting, though we are at the beginning and need to experiment.

I have to experiment with the performance of Camunda, but not yet in production. I haven't put any solutions in production yet, so perhaps performance is better as we see in documentation.

I have been working with Camunda for six months.

We have to wait to see if Bonita provided us with some features that Camunda does not or if we experience any stability issues.

I have not yet had any downtime that required raising tickets or any integration issues because Camunda does not support some of my tools or data.

I have not contacted the Camunda Technical Support team at any point, though perhaps members of my team have.

For the initial setup, the whole process takes about one day perhaps, two days, as the process is simple and we don't have any difficulties.

We are using the open-source community version, but I don't have an idea about the cost of enterprise edition to make a comparison.

Regarding pricing, we are right now working with the open-source Community version, but I don't have yet an idea about the cost of the enterprise edition.

I can talk about our experience with Camunda. For the moment, we are not using any sort of AI with Camunda at all, but for other technology, we use AI.

I am a co-founder of that enterprise.

I rate Camunda an eight out of ten for the moment because I don't really understand the exact parameters of the scale. It is still in proof of concept, and when it goes into production, I will have more ideas on how it should be done.

We use the workflow only in Camunda. It acts as libraries for workflow visualization, focusing on automating my company's processes.

Camunda is used for process automation with the bot automation. We use API from IPT software, and Camunda serves as a service for workflows. It has improved the cost benefits on Google Cloud.

Camunda serves as an automation library and provides lightweight deployment to the cloud. The personal thing for workflow automation is significant.

Camunda needs to improve its user interface for low-code development and provide more user interface options beyond the basic workflow. It also requires further development to compete with platform features, like the deployment and development life cycle.

We started using Camunda one year ago and began implementing some processes on the platform.

Camunda has benefits concerning the cost on Google Cloud, however, we have to invest more in development for scalability.

We have used IBM BPM before, however, Camunda was adopted for certain processes. Camunda doesn't require a license and offers a free version.

Camunda is cheap because it doesn't require a license. We can use the free version and manage everything in the company.

We plan to use Camunda workflows and relate them to IBM BPM in the future.

Camunda's platform could benefit from better UI for low-code development. Other competitor platforms have more comprehensive tools for deployment and development.

I'd rate the solution seven out of ten.

It is usually used to orchestrate or automate flows of interaction between our systems. It is basically for integration. For example, for a permit that needs to go through several systems, in Camunda, we have a business process that orchestrates all the steps where the permit needs to be processed. All the systems are notified of this permit, and if there are people who need to interact with a specific permit, they get notified. They can then take action. That's the kind of use case for which we use Camunda in our organization.

For myself, the use case is similar, but it is for invoicing. When we receive an invoice, we need to process it. It goes through the business process. There are a lot of business rules that are applied to it. For example, we will check whether the total amount is balanced with subtotals and tax, and if that's not the case, with Camunda, we can create what's called a user task. It allows us to make an agent to take care of this invoice and fix the data that is related to it. These are the use cases that we are trying to achieve with Camunda. The goal is to clean up the invoice and make sure that the information related to it is correct so that it can be transferred to our ERP to pay suppliers.

It is on-premise, and we've been able to put it in a Docker container. It is deployed in Kubernetes in our organization.

The main benefit is automation. When you don't have such a tool, you take a business process and try to interpret it in terms of code. You don't have visibility. Camunda helps an organization to see the process. If you see that something is wrong in your process, you can easily adjust it to fix the issues. There is a tool that comes with the Enterprise version of Camunda that allows you to see where most of the tasks or processes are merging in your business process. So, you can update and optimize that. If your organization uses Camunda to automate processes, you can have enormous gains from that.

It is a great tool. It was our choice to use it. It works well as a universal process orchestrator for complex business processes. It allows us to focus on the business process itself. If you want to orchestrate multiple calls to external systems and you want to be sure that all the systems are notified, it works great. My use case was more business-oriented, and it worked great for that. As a universal orchestration tool, it is good and powerful.

It allows business users to create, update, and execute complex workflows. This is important for us. We are more project-oriented, which is also the way most organizations work. We have a lot of developers during the development, but when we reach a point where the solution is built and we are in an operational state, we prefer to have a tool that can be used by the business. They should be able to configure and personalize their solution without requiring developers to do it. They should be flexible and autonomous in doing that, and we in IT don't necessarily have to have developers for that. We can focus on other projects. There are a lot of benefits to working like that.

Its ease of use is important in allowing us to automate processes. For my personal use case, it simulates a type of virtual agent. It allows us to gain greater value because people don't have to work on basic things. Camunda is doing it instead. We are adding great value by using Camunda for small things.

It has the ability to integrate with a variety of automated and digital systems, which, for us, was a prerequisite. It was important because if it could not interact with our system, it would have been hard to automate anything. It would become just like a business process to orchestrate people instead of the system. Therefore, it was important that we have connectivity with other systems. In the version we have, there are no specific connectors. There are more generic connectors, such as HTTP connectors. This might have changed in the new version, but the ability to interact with other systems was a prerequisite for us. If it didn't have this functionality, it wouldn’t have been interesting to use Camunda.

It helps bridge communication gaps between our development and business departments. Because everything is visible, the developers could see exactly what the client is trying to accomplish. To have something that we can see or even touch was interesting. It reduced the gap between two things. Only connectors were a little bit hard to understand for the business people, but developers were there to assist in configuring the connector. They had to work together, but the main focus was on the business, and it helped the developers in understanding what the business was trying to achieve.

Camunda automation has freed up our staff's time to focus on other valued tasks. When we are developing our solution, we have sprints of two weeks. We organize our work for two weeks, and regularly, we have tasks related to the business process and how we need to update it to adjust to some reality. Now, we have people from the business who are doing it, but it is still visible to the developers. It has saved the time of at least one developer for the two weeks because the business is able to work on that alone. We have five or six developers, and now, they can focus on the technical side of the solution.

Before Camunda, we had a lot of people interacting with the invoice daily. We had, for example, an agent who was doing 300 invoice checks and validations per day. With Camunda, those people are now handling only more complex checks and validations. Our processing time for an invoice is reduced from about 30 days to 10 days. There is about 70% saving of time.

We can easily define and deploy business processes. Camunda provides the tools that allow business people to design business processes. We don't have to have developers for it. It is so easy to use that our business people can go into the tool and model their business processes. We get time to do other things than just designing business processes. They are called business processes because it is the business that's driving them. So, it is better that they can design them because they're the right people to design them. The tool is great for that.

Transition-wise also, it is good. For example, if you have a defined business process with an invoice, and then for some reason, the business people decide that they want to add the business rules in their business process, they just can take the latest version of the business process, add the business rule, and easily deploy the new process to Camunda. Magically, all the new invoices will go to the new process, and the old ones will remain until all the invoices are processed. It is very easy to transition between all those business process definitions. These are the two most interesting features that Camunda provides.

We're trying to put the people from the business to do it. We are using APIs, and we have open APIs to define our APIs and the request-response that each call requires and sends. So, to base the mapping on that, there was nothing to help. I know that with some tools, such as Oracle tools, you can see the input and expected output. With drag and drop, you can take one property from the left and drag it to the right, and it does all the mapping itself, but that's not the case with Camunda. So, for me, this is something that can be improved.

If you stick to the basics, it can be pretty easy. If you need to extend, as we did with custom plugins, this is rather hard because the documentation is not that great. Everything is there. It is an open-source tool, and we had access to classes and documentation, but there was no great explanation on how to use them. There were also not many examples. It was pretty hard to go this way, but if you stick with the basic functionality, it is a great and easy tool.

Another thing that we struggled with has already been fixed. They now offer a SaaS version of Camunda. We struggled a little bit with how to deploy Camunda in our infrastructure. The way it was designed was that the database can easily become a performance bottleneck. It is something that they could improve. They can provide more examples of how to implement a scalable solution using Camunda.

My organization has been using it for around five years. For me, it has been around two years.

We had to do a lot of tweaking. It hasn't been stable from the beginning, but with some effort, it can become stable.

It is limited. The way it works is that when you are starting, you have to create a full autonomous Camunda instance with its own database. It can work, but it is not out of the box. If you want to have minimal scalability of Camunda, you can do it, but it will be linked to a single database, which can become a bottleneck. So, if your database sizing is not great enough, when you scale Camunda, there will be a performance issue. Usually, it works great, but it depends on your business case and your intent in using Camunda.

Our experience was great. Usually, they were assessing what we did. They were asking us to provide our configuration, and they were responding fast. It is different for different organizations, but I personally always prefer that they don't do the work for us. They should provide more advice and then we learn from that. They had the same approach, and I was happy with that. We used their consultant two or three times, and each time, it was a great service. I would rate them an eight out of ten.

Positive

We started with Camunda. 

We have three instances of Camunda running, and inside Camunda, there are multiple business processes for different solutions. For example, we have different types of permits. Each one has its own business process, and everything is deployed on Kubernetes. We have about 10 or 15 endpoints that are used through connectors.

Its setup was a little hard. The documentation was not that great at that time, and they had a lot of versions. What made it hard was that their recommendation was changing. For some time, they were providing a Docker image, and then they changed to what they call a green stack where we were using spring boot to achieve that. I'm not sure what it is now, but I know that it changed again. So, it was hard to follow the best practices related to Camunda at the beginning. It came down to documentation.

Overall, it took weeks. To have something running was fast and took days, but we had a lot of tweaking to do. To be advanced in our solution development, we did stress tests and had a few problems with that. We were trying to adjust the configuration, and the documentation was not always easy to read. Sometimes, the configuration was easy because we had to adjust the configuration just with the XML file. Sometimes, we had to go a little further in Java. There were different levels of tweaking. Overall, it was fast to have the initial version of Camunda running, but it took us a lot of time to have something production ready.

We started doing it in-house because we wanted to acquire knowledge about that. After a few weeks or months, as we were getting closer to our production date, we got the Camunda Enterprise version. One of the things that came with that license was support from Camunda. So, we contacted them just to update how we did our configuration. They found that we had a lot of instance processes, and because of our level of history, it had a lot of extra data. They provided us with scripts to help clean our database from unrequired data. So, in the beginning, we didn't take any help from a consultant or Camunda, but as we were near our delivery dates, we took some help. Even when we were in production, we had some issues. We contacted Camunda for some things that were not working correctly. It was just to get advice on how we installed things. It was okay, but it required some adjustment.

In terms of the number of people involved in its deployment, because it was something that was considered complex, I did it myself just to have the basics, and after that, when there was something to adjust, the team did it with me. So, it was me, and there was a team that came after.

In terms of maintenance, the way they have made it, it is pretty low maintenance. If you want to upgrade the version of Camunda, you just have to go into the dependencies to adjust the version. Inside the version, there's always a migration script that is embedded in the version. So, it isn't self-maintenance, but you just have to change the version, and everything is done magically.

We're using the free version. We used the Enterprise version for some time. If I compare free versus what we paid at that time, the Enterprise version costs a lot. For the additional functionality that we got with the Enterprise version, it was too costly.

The feature that appealed to us in the Enterprise version was the migration plan. If you have a business process, for example, with an invoice, and you deploy a new version with a new invoice, for certain times, you will have two business processes running, but we wanted to have only one process instance running at a time. So, we have to migrate the old process instance to the new process definition. They provide the APIs for doing that, but it can be hard. If you are at the node in the old process, you need to tell the engine that you want to migrate it to another node in the new process definition. Doing that manually can be hard. If your business process doesn't change that much, it can be okay, but in the case where it changes a lot, the Camunda Enterprise version provides a user interface to help map the migration between the nodes. We have long-running processes. For example, we could have invoices that are stuck in this process for 10 or 20 days. So, to migrate, we can't wait for the invoice to be processed because it is taking too much time. So, the tool helped us to do this migration planning, and that was one of its greatest features. 

Another appealing feature was that if something happened in your process and you want to debug to see what is going on, the Enterprise version provides a user interface to easily follow the progression of your process. For each node, you can see what changed at what time. That was very helpful when we had a problem with our process. These were the two features that helped us a lot because, at some point, we had some problems using Camunda. Having the Camunda Enterprise version helped us to fix those problems and helped us migrate, but when you have something more stable, as we have right now, those features are less important. We are no longer using the Enterprise version.

In terms of TCO, because it is an open-source solution, it was limited to the time that we spent integrating it. It took us a full year to integrate it into our system. It took a lot of time, which cost us a lot. The cost is also related to the infrastructure. For example, our database is getting bigger every day, but it is not much. Overall, it didn't have a big impact on our functional budget.

At that time, it was one of the few open-source solutions available in the market. For us, it was easier to go with Camunda. We are a government organization, and we need to go through the request of proposal process to acquire a solution, but we didn't for Camunda because it was open source. 

We quickly liked how it was working. It was a no-brainer at the time. We knew that we wanted a workflow engine, and it was only Camunda that provided the level of flexibility that we were searching for and was open source. That's why we went with Camunda. We didn't find any other interesting providers. Now, I know there are a lot more solutions. So, if we have to start over with a new solution, we will take time to see if there are any other tools that can achieve the same.

The most important thing would be to do a proof of concept before going too far. Some tools are very stable and you can go with them right away, but with Camunda, just because there is so much to know, it is better to do a proof of concept before going all in.

The connectors provided by Camunda can be enough. It depends on your use case. By default, there is an HTTP connector, and there is also a SOAP connector. It is easy to use the connectors. They provide a base connector, and you can build it more. In our case, we had to go a little further and develop plugins in Java, which was a bit of an issue because it is not our main technology stack. We don't develop much in Java. So, there was a learning curve for developers, but overall, it went well.

I know that Camunda offers a user interface for people when they need to interact with it. We didn't use it in our case because we found the user interface too simple. It was not providing us with enough information. and the other thing was that if a user is working in system A and had to interact with Camunda, he had to leave his context to go to system B and do the task. So, in our case, we decided to integrate it into the same system to provide all the information that a user needs to accomplish a task. So, it is a bit limited in that aspect, but the fact is that when you use Camunda, what you're trying to achieve as a goal is to prevent people from interacting too much with the process. So, it may not be a problem if the user interface is not as rich and complex.

I would rate it an eight out of ten.

The solution is used in my company, where we deal with insurance.

In our company, we use Camunda to automate our process to reduce the need for human tasks. In short, my company uses the product to reduce the need for manual work. The tool can help automate processes like insurance claims, onboarding, and other areas that are managed manually. Various processes in our company can be converted to automated ones with the help of Camunda.

The best feature related to the product is that it offers users a zero-code or no-code platform, so people can use the product without being developers or knowing Java or other microservices.

The support offered by the product is an area of concern where improvements are required.

Though Camunda offers one of the best support services in the market, I know that Camunda Platform 8.0 is still in the development phase. The tool can have more guidelines and best practices that can be made available over the internet to help people who are researching the solution as it is a new product in the market.

I have been using Camunda for a year. My company currently uses Camunda Platform 8.0. I am just a user of the product.

It is an absolutely stable solution.

It is a scalable solution.

Camunda is a new product in our company, but once we show the abilities of the tool and showcase it by going live with the solution, our company's entire client base will open up.

There are no admins required to take care of Camunda.

My company plans to use more of the product in the future.

Camunda is the first tool that we have used in our company. I believe that Infosys was using IBM, but they also moved to Camunda recently.

The product's initial setup phase was neither an easy nor a difficult process, though my company did receive support from Camunda, considering that I work in a big company with firewall products in place. There were some hurdles during the setup phase, making it a not-so-smooth process, but my company was able to deploy the product successfully in the environment.

The solution is deployed on an on-premises and on the cloud model.

Compared to some of the major players in the market, like IBM, Camunda is a cheaply priced product, making it one of its major USPs.

My company chose Camunda since it has two parts, one of which is Camunda Rule Engine, while the other one is Camunda BPMN. When it comes to Camunda Rule Engine, Camunda passes a set of rules through the tool itself, a process that doesn't happen in the system but happens externally through validation checks called the Camunda DMN Decision Engine. After a certain period, my company realized that Camunda's main feature lies in what Camunda BPMN provides to its users. After getting a demo of Camunda, my company was impressed with the solution, and we decided to try it.

Camunda's website is filled with a lot of knowledgeable stuff, so it is important to get in touch with a person from Camunda. By just going through the website Camunda, it is possible to strengthen your understanding of the fundamentals of the product. Camunda also provides free courses to those who want to learn more about the product.

I rate the overall tool a seven and a half out of ten.

I worked on a project in Pakistan. For this project, I replicated processes on Camunda, including BPDs (Business Process Diagrams) and activities. Currently, I am working on the forms aspect of the implementation.

I appreciate Camunda's strong SLA agreement, my current bank client required customized forms. Camunda forms are built on Angular, and I'm currently involved in a headless reporting project with Camunda.

Camunda's front end is built in Angular, while I'm integrating the Java backend services. I'll consume the Java services and handle integration with Angular on the front end.

When deploying Camunda, I prefer a headless approach. This means Camunda acts as middleware while the front end is built using a different technology. And back end will be from the different technology. 

 I've integrated a database with Camunda's process engine. This allows me to generate emails and update the database as needed.

It is very user-friendly compared to IBM BPM. It's much simpler because it doesn't have the process admin and process inspector roles and separate pages – it's more streamlined. That means even non-technical departments can use it. 

If we don't need complex, high-level workflows but just a small form-based process, Camunda can be used by any type of client – technical or non-technical.

I don't see a lot that needs improvement in the core functionality. With the on-premises version, the task list has issues, and user creation is not as straightforward as in IBM BPM with its Process Admin role. 

Camunda also lacks some of the initial documentation that helps with onboarding. I often rely on Udemy courses for help.

So, basically, on-premises user management needs improvement.

I'd recommend a feature like the Process Inspector that IBM BPM offers. This is where you can troubleshoot and manage running processes. It would be very helpful for non-technical users, as sometimes they need insight into where a process is stuck. 

Camunda Cockpit has similar functionality, but it's a bit more complex. I'm a technical person, so I understand it, but our clients are often from non-technical backgrounds. My clients are mostly common users from commerce backgrounds. 

So it would be better for Camunda to be able to easily view their processes and troubleshoot process instances.

The Process Portal in IBM BPM is basically a dashboard view. If Camunda could offer a similar dashboard for users, it would be a big benefit for their organizations.

I have been using it for six months. I use version eight. 

I would rate the stability a seven out of ten.

I would rate the scalability a five out of ten. Scalability would be improved with better documentation and resources. IBM BPM, for instance, offers extensive documentation and support teams for various issues. Camunda's documentation feels less comprehensive in comparison.

Additionally, it would be helpful to have more readily available use cases on the internet. This is important for doing POCs [Proofs of Concept] and showcasing how Camunda can be used. IBM BPM has many example use cases for systems like currency exchange or HR management. 

Camunda lacks this, often showing only very small processes that can be difficult for clients to envision within their own needs.

So, the lack of readily available use cases affects the ability of Camunda to adapt to your customer's needs.

I have experience with both IBM developer tools and Camunda. 

Due to cost considerations, we often recommend Camunda to smaller clients where IBM solutions might be too expensive in Pakistan, especially for small companies. 

I also do POCs [Proofs of Concept]. The demands I receive from customers are varied, but they want to move forward with the technology. If Camunda fulfills their requirements, they will definitely adopt it. Before Camunda, I also worked on Appian, but it wasn't as exciting as Camunda.

I'm doing a Master's in Data Science, so I know how crucial decision-making is for customers. Once my first POC is done, I'll definitely explore decision modeling. Camunda is still in its early stages in Pakistan.

There aren't as many resources in Pakistan as there should be.

I would rate my experience with the initial setup a nine out of ten, with ten being easy. Installing Camunda on your machine is incredibly easy. It's even easier than installing MS Office. I also installed IBM BPM on a virtual machine, and that took me one or two weeks to configure fully. Camunda is much simpler in comparison – the process is similar to installing MS Office.

Most customers I have are in the banking sector, so they prefer on-premises deployment. 

It takes around three days to deploy the solution because it includes things like permissions etc. Camunda is significantly quicker to deploy in comparison to IBM BPM, which takes around ten days. 

I'm a developer, not an administrator. So, I usually work with the administration team for the actual deployment. Typically, we need a few key files: one for the setup and one for the Camunda server itself. I'm familiar with the server file since I have Camunda installed for development on my own computer.

Compared to IBM BPM or Appian, Camunda's pricing is good.

Camunda is significantly cheaper than IBM BPM, especially considering the SLA agreement. Of the three products, it offers the best price-to-value ratio.

Overall, I would rate the solution an eight out of ten. 

I'd recommend it if you're currently paying a high annual fee for a solution like IBM BPM. Camunda is much more affordable while still offering a strong SLA agreement and security. 

It's worth trying – perhaps initially with a smaller process in your organization. You could even test it on a UAT environment before going live. I often recommend this approach to clients, as it's a good solution for many use cases.