Camunda Reviews

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.

We have an event-based architecture and Camunda works as an orchestrator for our microservices.

Over the last three years or so, we have been using Kafka a lot. We wanted to bring in an orchestration engine to integrate seamlessly with our nesting system. We had a lot of existing applications that are not that old, and we did not want to rewrite software components that we own to get the benefits of orchestration. That was where there was a need. One of the factors that will decide if we will use it for more use cases at our company or not, is the ease of integration.

As an organization, we don't want to reinvent the wheel, so it's important to us that the connectors are available out-of-the-box and reusable. We don't want our developers to write boilerplate code. Having the connectors ensures that we have standardization in the way that we are integrating with other parts of our ecosystem. It also allows us to put some best practices into those standards. For example, we can implement three tries for a connector. That helps us be declarative. It provides a good tradeoff between low code and no code.

It has a ubiquitous language across stakeholders. When we are talking to stakeholders about how a process evolves over time, or about the complexity of a process, it's a lot easier to explain without having to go through Confluence pages or through a lot of sessions with product people explaining to them how a particular system works. They have a good amount of understanding by looking at the process diagram. That really helps me, personally, in communicating with them.

We have also been able to build out dashboards for our asynchronous processes. Those dashboards have been really helpful. Otherwise, we would have to rely on the data analytics team to provide us with any analytics data around the events that are flowing in our system. Now, for some of our purposes, we can build dashboards ourselves using Camunda.

In addition, we have built dashboards that show important statistics about our business process and key changes that happen in our process definition. Those changes communicate a business value to our business stakeholders. For example, in the last seven days, how much traffic have we ingested into our system, and where has most of it gone? That kind of information is now more of a self-service for everyone. The dashboards we have built are giving us a good amount of information about what's happening in our systems. We are also using the BPMN designs for our design discussions with the product team.

We have been more agile because we don't now have to keep the Confluence documentation up to date. When you put something in Confluence, it's hard to keep it updated and make sure that it's up to date with the latest implementation. Now, the business process flows are code. They are modeled as BPMN files, so we don't have to make extra effort to maintain the business process. And while we are discussing our product, we can communicate how the small things that are part of a process could build up and what role they are playing in the overall process. It also helps us find out, if some part of our process were to fail, what impact it would have on the overall process execution. That's something that teams have recently started discussing more.

Since day one, our goal was to build reusable components that can be used in other projects. We recently did a discovery for one of our projects and we found that we could reuse 80 percent of what we had developed on the Camunda platform. The microservices and the connectors were reusable and that really reduced the development effort drastically for that use case.

We are now spending more time looking at the bigger picture, and not just looking at a particular microservice. The developers can now see where their microservice fits into the flow and how their microservice responds, whether in a successful manner or in failure.

The integration with almost any language, product, and even human tasks, is valuable. It's very seamless to integrate into existing systems. It doesn't require you to rewrite a lot of your existing system. That's where it really stands out.

We have used a couple of connectors, including the Kafka connector a lot because we have mostly a Kafka-based architecture. The connectors are really seamless. They just fit in. They don't require you to make a lot of changes to your existing infrastructure. That's what connectors are primarily meant for, to enable enterprise-level integrations. We also build out custom connectors for our use cases.

In addition to Kafka, we can easily integrate it using any microservice or legacy microservice. All you need to do is include their library and put in a couple of annotations on your existing methods, and they can act as Camunda workers. You can transform your existing code into Zeebe components and that requires very minimal coding. We are also working on building more connectors, and that will smooth out further adoption of this technology within our ecosystem. We can orchestrate almost any remote system if it's accessible over the network and it implements any protocol. If it's reachable, we should be able to orchestrate it via the Camunda platform.

In terms of its ease of use for engineers, it's pretty easy. We have an engineer who joined us two weeks back and he has been onboarded. He's able to make changes in the BPMN. That's very important for modifying business processes.

We have been using Camunda Platform for a little less than one year.

We anticipated the load for one year, at least, and we have done load tests. The system is pretty reliable. We have not had even a single issue in production using their product. It's very reliable.

It is very scalable. It's built on a similar architecture to Kafka, which we know is a very scalable platform. The scalability has been one of the most important features that they have designed their product with. They had scalability in mind from the start. 

We have tested it for thousands of process instances per second. There are some blogs from Camunda that show it even goes to millions of process instances per second.

While it's very scalable, it would be great if auto-scaling capabilities were added to it. We haven't seen any issues in production related to scalability, but one area that really could help out would be to have dynamic resizing of the cluster. Right now, you have to do capacity planning. You plan for the capacity that you need in the next couple of years and then size your cluster accordingly.

Having said that, I haven't seen problems with the product so far.

I would rate their technical support a nine out of 10. The one thing that I feel there could be more of is their exposure to AWS. I'm not saying that they don't know about AWS, but I think a lot of their customers are using Google Cloud. I think they, themselves, deployed it on Google Cloud. But AWS is the market leader and there are a lot of customers on AWS.

Positive

We have used AWS Step Functions.

They provided help charts, so it was pretty straightforward. But when you want to tune it or run it on an enterprise level, you will want to try out a few of the parameters they have provided, and play around with them, to ensure that the software components that your cloud provider has can be used smoothly for deploying Camunda. Initially, you might have to make some effort to set things up on your own cluster, but they have good documentation and help charts for deployment on your Kubernetes.

We have different environments, including development, testing, staging, and production. We could even implement a CI process for our workflow instances and BPMN files, as they can be deployed using a CI/CD pipeline. Microservices can be deployed at their own pace in a CI/CD pipeline. That was the strategy for deployment.

We did it in-house, but we did use some consulting from Camunda during some of our initial days. One of their solution architects was really good in terms of technical knowledge. He knows the product really well and he guided us through some of the parameters and tuning of our clusters while we were deploying.

In addition to me, we had one more person doing the deployment. One of our senior people took care of the deployment on our side. I was overseeing things but he did most of the work.

So far, we have been very pleased with what we have achieved with Camunda. We are still within our initial one-year contract but we have seen value from it.

In the use case where we were able to reduce 80 percent of the development effort with reusable code, that equated to man-hours that are directly related to cost. If you reuse code for more use cases, the cost can be justified.

We have an on-premises, self-managed installation because of some internal decisions. There is a bit of scope for improvement in how the licensing and pricing are done. They are based on the number of processing instances you execute on the cluster. They have two modes of deployment, one is their cloud version and the other one is the self-hosted mode. For the cloud version, it definitely makes sense to have it based on the number of processing instances you run, but on the self-hosted mode, the pricing model should be customized. If it were customized a bit more, it would be better for us.

We purchased their workflow engine, Zeebe, and consulting. We also operate the tool with which you can monitor your process instances. There are a couple of more tools available in their product suite, but these three aspects were most compelling for us. If we are running mission-critical workloads, we definitely need support if things go wrong on a given day. We need their expertise, so the consulting is very important for us. The workflow engine itself is also very important, as that is why we evaluated Camunda in the first place.

If data privacy is not an issue, then definitely go for the cloud version of Camunda because then you don't have to worry about managing the cluster and capacity on your own. It's more seamless than having to manage your own cluster. But if you're considering upgrading from the free version, the consulting is definitely important. They also do BPMN consulting as part of the contract. You can ask for BPMN reviews and you can ask for sessions with their solution architects. They also have a 24/7 hotline that you can call in case there are any issues.

They have an excellent open-source community. I have not seen many other forums that have developers who are as active as Camunda's developers are on their forums. The technical advice that we get from Camunda is really helpful. They know best about the product they have built over the last few years. You definitely need to have expertise on a product that you're thinking of using. The people who have built it provide a great additional value.

We did take a look at some of the options available in the market, solutions that allow you to do process automation, including Cadence/Temporal.

We selected Camunda due to a few important reasons. It's a product that solves a problem that many organizations don't even realize exists in their architecture: visibility. It gives us visibility into the complex processes that are often implemented in software or if some of the tasks are done by humans. Camunda, with its integrations and great tools for reporting, like Optimize, allows us to see where the bottlenecks are in our processes.

It also has companion tools, like Operate, that allow you to visualize the flow of a particular business process. And you can find some really cool statistics about how much of a process is actually done or where it is blocked. Those are some of the really important features that any workflow orchestration or engine should have, and Camunda supports them pretty well.

Take a look at their co-founder and CTO, Bernd Ruecker's, blog. He has a lot of good write-ups about the platform where he explains the technical architecture. He talks about how to do performance benchmarking.

Another good piece of advice is to leverage the Camunda community and forum. Their team is very active on the public forum and they respond to your questions within a day, most of the time. They give very to-the-point answers. That is a really helpful resource. They also have a good set of tutorials on BPMN in what they call the Camunda Academy. It's worth taking a look at that when you are adopting the Zeebe workflow engine, which is their primary workflow engine.

One of the important things that we want to deliver is enabling business, developers, and operations. It's important that our non-technical stakeholders don't have to get into the nitty-gritty details of technical implementations. They can have a bird's-eye view of what's happening in a process, and they can suggest or even extend a process by themselves and then hand it over to us as a requirements document. That's the direction we really want to take. So far, the product team has been very enthusiastic about it. They like it. Camunda uses a language for modeling called BPMN and it doesn't require you to be a coder or an engineer. It's a simple drag-and-drop tool. It's really cool and it helps our stakeholders to be involved in working with workflows.

There is a bit of a learning curve with BPMN. It's an industry standard, not something proprietary to Camunda, but Camunda hosts an online academy where they have tutorials about it. They have videos and free courses on how to use BPMN. That helps out in the onboarding of users.

We have been using it for a little less than a year, so our entire organization is not using it. We are really into building our experience with Camunda by applying it to a few use cases. As we see more use cases in other parts of the organization, what we have built over this past year as templates—as reusable software—can be leveraged so that they don't have to set up everything from scratch on their own.

We are a fintech company located in Argentina, and most of our use cases are related to transferring money from one account to another and doing the orchestration with financial institutions. 

It is also used for the orchestration of all the documents for onboarding. We have electronic onboarding where you give some information about yourself, and then you take a selfie and provide photos of the front and back of your document. We have to orchestrate all this information in order to validate it with a third-party bureau of data. When we receive an okay from the bureau, we know that you are an active customer, and we can give you an account.

In terms of deployment, it is a public cloud. We have Amazon Web Services running inside a Kubernetes cluster. 

We are a startup with less than 200 people. We first started doing orchestration using code, but after two sprints or about a month and a half, it became very clear that we are just generating spaghetti code. No one could understand the code after one month because it had difficult logic based on what an engineer thought would be a good idea, such as creating a new branch of decision, and if it wasn't very well documented, you wouldn't understand what was going on. Another drawback of having such a code was that we couldn't make the business understand what was going on there. So, it was very difficult to do things faster. That's why we decided to look for an orchestration tool, and we decided on Camunda as a solution. The way we could orchestrate everything was transformative. We went from having to code to drawing our processes. As of today, Camunda is used for every process here.

It is very good as a universal process orchestrator for complex business processes. We are using it for microservices, not for a human process. We had thousands of processes happening per hour, and the tool was able to capture the data for this throughput. The thing that wasn't aligned was the pricing structure. Camunda On-Premises is more designed for a human process where you have to have some kind of manual processing. We had a lot of back and forth with the commercial team because of the price of the licensing due to the volume that we had to process. That's because every time we wanted to send $1, we had to start a new process or several processes. This was a drawback, but in terms of the project, the product was very good and robust. Process heatmaps show the process steps that are hanging or taking significantly longer. You can go there and see the values and debug those. So, it was very useful for not only orchestrating what we have but also in understanding where we have made a mistake with a production process.

When it comes to integration, because we are a startup, we don't have any legacy systems, but we use it to connect with the legacy systems of the general payment system in Argentina. It was very instrumental for this use case. We had our own logic for how to connect and how to do the interface inside our microservices, and we used Camunda to verify the correct logic and sequence of calling different microservices, getting the response, and handling the response.

The dashboards are helpful in making the business understand what we are talking about and what can we do in certain situations, such as, if the money doesn't arrive at its destination. We had the drawings, and we used them to ask, "For the arrow here, what should we do?" We were able to have the conversation in a clear way. If we had just the code, it would have been very difficult. To have the conversation with the business, we would have had to create a drawing on a whiteboard and hope that this drawing is exactly what is happening in the code.

It freed up the time of our technical leaders working on this part of the system. By using Camunda, we could have the application process design, and we could quickly deploy the system to production and have the product early on the market. That was our biggest gain. We didn't have engineers struggling to orchestrate microservices.

The BPMN diagram is valuable. For our use case of transferring money from one account to another, the connections have to be done in the traditional financial ways. There are a lot of unexpected errors and a lot of instability with this kind of system, and we are using Camunda in order to have clear flows. With BPMN, I can show a flow to my business partner, and the business team can easily understand what's going on. The technical team can understand what the implementation is, and we can model different errors and the process for recovering from these errors. For example, it is very common that you make a transaction, but you don't have a response from a bank. You sent the money, but the bank didn't confirm this. Such errors have to be handled because it may mean that you have to do a reverse transaction. We are able to solve a lot of orchestration problems by using Camunda. Most of them are related to payments or sending and receiving money.

The feature where you can have dynamic tables with values and actions inside the BPMN is very good when you don't have all the possible responses. We may think that the payment system is very robust, but it is not. Sometimes, we receive an error code that we weren't expecting, and this kind of solution helped a lot with that.

Camunda has licensing per process. There should be a different kind of licensing so that a company with thousands of microservices doesn't have to pay per process. It would be very useful for us. Their current licensing is very difficult for us to maintain. When you have a lot of processes running, it becomes very expensive very quickly.

It has a Postgres database at the backend, and it is very difficult to scale if you increase the number of processes running. We did hit some barriers. We were able to overcome them, but it was a problem. Camunda has another product called Camunda Cloud, which supposedly doesn't have the same scalability problems, but we are not using Camunda Cloud because the set of features is smaller than Camunda On-Premises. So, its scalability can be improved. Because it has a single database, it is more difficult to scale if you have a huge success.

We use our deployment pipeline to deploy the BPMN process. We have a continuous deployment system where when you finish your development, you are able to deploy the BPMN file as well. Sometimes, when the engineers are deploying several BPMN processes in parallel, we receive an error for Camunda, and we are unable to do the deployment. It is a very specific issue, but we have found that automatic BPMN process deployments sometimes fail in Camunda. When we try to deploy several at once, the system isn't strong or robust enough. So, there is room for improvement.

I have been using this solution since October of 2020.

In general, its stability is very good. 

Scalability is something that we have been worried about because everything that runs in Camunda is run using Postgres. It is very difficult to scale when the number of processes increases. Because Camunda uses Postgres, we had scalability challenges. We had to do a lot of fine-tuning in the Postgres database to support increased processes.

The main problem with scalability is related to the database. That's why they created Camunda Cloud, which is Zeebe. They know they have this dependency on Postgres, which is hurting its ability to scale up.

Their tech support is very good, but it also depends on which support team you get. You can get someone who doesn't understand the whole thing. 

They have been very supportive from the beginning. I believe that they didn't have our type of use case before where a fintech company is using Camunda for its microservices. We could see the same people who were committing the code in the open-source version providing the support to us. It couldn't get better than that. 

I would rate them a nine out of ten. Sometimes, we had a junior engineer, and it took a lot of back and forth communication to have the answers, but in general, we have had a very good support experience. 

Positive

We started with Camunda.

It is kind of straightforward. We have everything configured as infrastructure as a code. So, we got the best practices from Camunda, and we wrote our deployment instructions for Camunda's deployment as code by using Terraform. We did that on our side, but it would be very good if we can get it from them, but I understand that each client probably wanted to have their own method of deployment.

Camunda's deployment was easy, but fine-tuning the Postgres that we had as the backend database wasn't easy. 

After the deployment, it took us two to three months to wrap our minds around how to use it correctly. After that, it was a matter of creating templates that our team would be able to leverage and start using more and more. It isn't a very difficult product to understand. It has its quirks, and that's the part that you have to learn and has a steep learning curve, but when we did our due diligence, Camunda seemed to be more mature and straightforward than its competitors. I value it very highly.

Everything was done in-house. I built a very knowledgeable technical team. We had DevOps, and we had frontend and backend engineers. We had a complete team dedicated to making the startup grow. There were two to three people doing the work for a few weeks, and we have been able to make everything work.

It is easy to maintain, with the exception of the database. For the Camunda instance, for example, it is very easy to maintain the licenses. It is easy to attach a license to the container, and we are good to go, but we also have to take care of the database. We have grown so fast, and in order to not have a huge Postgres database, we have to delete some of the instances, such as instances from a day earlier. We are deleting the processing history because the database couldn't handle all the data that was passing through it. Maintenance-wise, that's what I remember the team complaining about.

We have definitely seen an ROI. We are using it for all critical processes in the company. The dashboard and the BPMN part have been instrumental to our success.

It is good for a startup. When we started, its price was fair, but the way we are using it to orchestrate microservices makes it expensive. When you are growing as a company, you would have more microservices, and you would have more users. There is an exponential effect when you are growing in terms of the number of conditions, processes, and users because they bill you per process. So, the price was increasing very quickly for us, and it was very difficult.

The commercial team has been trying to find a way to have different licensing, and it seems that we have found a way. We're starting a conversation with them, but so far, our experience is that when you grow as a company, the cost increases very fast. It has been difficult for us. However, our use case was related to microservices, but that might not be the case with other use cases.

We purchased a license directly from Camunda. It was the first time that we were working with a process orchestration system, and the features or aspects of the paid license that appealed to us included support and dashboards. Having a dashboard helped us to understand which processes are failing and where they are failing. They have heat maps that show the paths that are more used in our process. It has been very useful to understand how things work in general, and then you can go and do a deep dive and select a specific process and debug it. You understand why it was failing. It has been very valuable for the engineers in understanding what's going on and how to fix a bug.

If you want to debug a process and also understand what's going on in different instances that are failing, the features in the paid version are very valuable.

The paid license features are instrumental for us. Because of the price increase, we are looking at alternatives. We are looking at just an open-source solution, but we really don't want to do that because we're going to lose a lot of features. The dashboard, heat maps, and visual administrative interface are not available in the open-source solution.

We did a little bit of research. We looked at Zeebe, which is their own. We also did research on jBPM, but it didn't have all the features. 

We were trying to solve a problem in our startup, and we just started to look for solutions. We didn't have a broad benchmark. We were looking for something that could work, and Camunda was fit for our needs. We couldn’t find anything that had the stability or robustness that we were looking for. So, we went ahead with Camunda.

I would advise comparing it with Camunda Cloud or Zeebe. If your use case allows you, go with Camunda Cloud because, this way, you can leverage this new system that has fewer scalability problems. It is not a straightforward recommendation because at least until last year, the set of features in Camunda Cloud wasn't the same as Camunda On-Premises. That's why we didn't use Camunda Cloud.

We didn't use any third-party connectors. We used Camunda and then we used just the HTTP connector to orchestrate our microservices. We didn't do a direct connection from Camunda to any outside or third-party system. With Camunda, we only wanted to orchestrate our microservices, which can then connect to third-party or other systems. We wanted to keep our architecture clean, and this piece of software was used to orchestrate microservices, which was great.

Camunda provides an interface where business users can create, update, and execute complex workflows, but we didn't use this feature. No one from the business side used it for creating their own processes or modifying anything. I used it only for microservices. Being able to have a diagram and being able to have a business discussion by using the diagram as a reference was good. It was very interesting because we could have all the teams and all the specialists on the same page, but I didn't have anyone from the business side or operation side directly using or connecting with Camunda.

It hasn't reduced the cost to design and implement critical processes. That's because we weren't using any other tool previously. So, I don't have a comparison. It also didn't have any effect on our TCO. We are a cloud company. We have a very modern infrastructure where everything is on Amazon. The team is very used to getting docker systems and running complex systems inside of Kubernetes. We haven't had any trouble running it.

I would rate this solution an eight out of ten.

We use the product to automate our workflows. It is used for task management.

Camunda is a good product. The product has a good task management engine. Camunda has had a good impact on our operational efficiency. The integrations are getting better. It has a lot of REST APIs. We can integrate the tool via REST. It is a good feature. It's much better than what it used to be.

Camunda is Java-based. It would be better if the tool were made less reliant on Java.

I have been using the solution for four to five years.

The solution is very stable. I rate the stability a nine out of ten.

The solution is very scalable. I rate the scalability an eight and a half out of ten. We have more than 100 users. I use the product twice a week.

We have used Flowable. We also used an IBM product, but it was not very good. We chose Camunda because it is more scalable. It has a smaller footprint. It is the most effective product.

The initial setup is easy. I rate the ease of setup a nine out of ten. The solution has multiple deployment options. It has its own cloud services. The deployment takes just a few hours.

We deploy the tool in-house. We've embedded it within our application. We need only one person for the deployment.

We use the free version.

The number of people required to maintain the tool depends on the application in which it is embedded. We might not need many people for maintenance. Our in-house team resolves all our issues, so we do not have to contact support. There is a lot of documentation available. They are very good. The solution has BPMN and DMN. DMN is very powerful when modeling business decisions. The rules engine is very good. I will recommend it for the rules engine. Overall, I rate the product a nine out of ten.

As a service company, we implement this product for different customers. It's quite useful in automating processes, particularly with its orchestration capabilities.

The visibility – the diagrams you create – and then being able to automate based on them are valuable features. It's easy to explain and comprehend, and the integration aspects are valuable.

Typically, the user integrates with the business applications by calling jobs using REST APIs and similar methods. When the user needs connectors to databases for fetching data – that's where it's useful. Also, until the previous version, the user could embed Camunda within other applications. That was a good feature.

The user interface is good from the development point of view. But it's not a no-code, low-code kind of thing. From a developer's perspective, it works well.

So, it might not be easy for non-technical people to use. Camunda themselves never positioned it as a tool primarily for business users. Business users could use it for the designing perspective and then hand it over to the developers.

In the latest version, there are certain workflow nodes that are missing. Camunda should bring those back, or rather, develop them quickly. We've seen some of this on their roadmap, so they're working on it.  

I have been familiar with this product for five years. 

Whatever issues we've faced, we were able to resolve on our own, so it's been good enough for us.

The open-source aspect was important to us. So Camunda has been a good fit.

We work with both the free version and the latest paid version, as well as version 7.4.

The pricing has been flexible. Overall, it's been good.

If a company has workflow automation requirements or needs orchestration, it's quite useful.

Overall, it's good and solid. At least up to version seven, which we're heavily using. Version eight is progressing, and Camunda will continue to add the things we need. I would rate it at least a nine out of ten.

I use the solution in my company for process modeling and collaborations with other users.

The most valuable feature of the solution stems from the area revolving around process modeling. It is possible to take care of the process modeling with BPMN. I think the most beneficial feature of the product is that the tool serves as a process orchestration platform and also helps in the area of process automation.

Camunda should be able to automate the processes in any department, like the ones in HR that are related to procurement or any others, which are repeated in the same manner without any significant changes in the process, as it is one area where the product faces certain shortcomings.

I have been using Camunda for about three years. I am a customer of Camunda.

It is a stable solution. I have not faced any trouble when using the product in my company.

Camunda is a scalable product.

Around 10 to 15 people in my company use the product.

I have never contacted the solution's technical support.

The product's initial setup phase is difficult for beginners.

The solution is deployed on the cloud.

The product's price depends on the number of processes that need to be automated or where the orchestration part needs to be used. The product is affordable for medium and large enterprises.

My company chose Camunda since we wanted a tool for process modeling with BPMN so that we could automate some of our processes.

I recommend the product to those who plan to use it, as it is a simple and practical tool with powerful capabilities.

The product helps achieve operational efficiency in our company since it helps with the process modeling area. The product also helps automate and orchestrate processes effectively.

Camunda's user interface's contribution to process modeling and deployment stems from the fact that it is pretty intuitive and simple.

It is easy for someone to learn to use Camunda.

I rate the overall tool an eight out of ten.

We use it in the banking sector for a specific project. The platform aids in optimizing and automating business processes, enhancing operational efficiency, and ensuring seamless workflow management

Its flexibility stands out as the most valuable feature. I am content with its courses and the support team.

When addressing a complex and extensive process, the domain it belongs to, be it banking, healthcare, or HR, requires widespread access.

We have been working with it for more than five years.

I would rate its stability capabilities ten out of ten.

It offers excellent scalability. I would rate it ten out of ten. Our clientele comprises enterprises, medium-sized businesses, and small organizations.

Technical support from Comodo is accessible exclusively with the enterprise version, and it is highly commendable. They offer two support options, including the provision of an individual technical support manager. Our customers benefit from having personal vendors in support, capable of communicating in their native languages. For instance, if operating in Ukraine, clients can expect excellent service with a personal manager fluent in Ukrainian. I would rate it ten out of ten.

Positive

The initial setup was straightforward. I would rate it ten out of ten.

When it came to deployment, there were readily available options, along with clear instructions tailored for an open environment. We have it deployed on cloud as well as on-premise. The deployment timeframe varies, measured in hours or days, contingent upon specific customer requirements. Frequently, we initiate development, reproduction, and production environments. However, delays may arise as these environments can differ slightly, necessitating additional setup time.

ROI is influenced by the quality and usage. While the pricing structure is crucial, making an error in the planning can lead to substantial expenses. However, based on the feedback from our customers, they express satisfaction with Camunda. They assert that it provides extensive coverage and is more cost-effective compared to other business process systems.

While the license isn't budget-friendly, careful consideration and calculated planning for a significant number of licenses can make it more cost-effective. The pricing structure hinges on three crucial parameters: process instances, how frequently processes are initiated, and the number of users. These latter two factors exert a considerable influence on the overall cost. However, for those looking to explore it, trying the cloud version is a viable option. The cloud variant starts at $200 per month. I would rate it six out of ten.

Overall, I would rate it ten out of ten.

We use it as a task manager. Our use case is to help manage human tasks and have a workflow to which we can assign a function and some criteria to agents.

Camunda helped in an important way because we have a standard language in discussions between developers and business analysts. It has been key in closing that gap.

And although we haven't quantified things, generally, this type of platform will reduce the cost of in-house development.

The UI is very user-friendly compared to other products. The native, vanilla UI is very interesting and intuitive to use. It's user-friendly when it comes to modernizing a business process. 

The connectors provided by Camunda work correctly for mapping out and connecting processes. Our strategy is always to use out-of-the-box products.

It exposes a REST API that it can facilitate and make it easy to integrate with other systems.

We are not continuing with Camunda because of performance problems. We have millions of cases and when we did load testing with Camunda we found some limitations.

It is not difficult to change existing processes. The difficulty was in integration, for example, to call an external web API, and in the security capabilities, to use a vault for secrets. That was difficult.

They also need to integrate business role management, because Camunda doesn't have a built-in business-roles engine. The business analytics monitoring, the BAM portion, could also be improved.

We have been using Camunda Platform for about six months.

It's very stable.

In our strategy, we use containers on-premises to manage scalability using Docker or OpenShift.

Camunda's technical support is very good.

Positive

We had a solution before Camunda, but I don't want to identify it because we did not have a good experience with it.

The installation was very simple. With Camunda, it's very easy in comparison with other products.

We set up a dev environment and a laboratory environment, and it took about five days, max. We hoped to expose Camunda to our end-users, not only IT users but also business-type users.

We haven't seen return on investment because we need more time with this type of product. It's a long-term investment. It will take three, four, or five years to see a return.

The price is competitive with products like Bonitasoft and RHPAM (Red Hat Process Automation Manager). We have two versions of Camunda. The first version was open source, without support, but then we got a supported version.

Other products, like Pega or IBM or Oracle, are very expensive.

We have evaluated Bonitasoft and RHPAM.

Camunda and other products—like Bonitasoft and RHPAM —have been chosen, strategically, by our enterprise to reduce the gap between developers and analysts, because we talk the same language: BPMN.

The only negative point was the performance. If a company wants to use it with small or medium-sized systems that do not need a lot of performance, it would be a good choice.