Camunda Platform Reviews

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

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

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

The best feature is the automation.

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

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

The support definitely has to be improved.

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

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

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

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

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

Support is an area that is in need of improvement.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

I would rate this solution a six out of ten.

We are using the product as an OAM that we have included in our software product. We are offering a private cloud solution and we sell it and deploy it to our customers. 

We are using it to create a low-code solution for strategic planning and performance management in order to automate the management processes such as planning, performance management, governance processes, and business process management as a whole.

We are using the BPMN engine of Camunda; we are not using the user interface. We are using just the engine, the back end of this. For us, it is working quite well.

The stability of the solution is quite good.

Technical support is good for getting alerts about bugs.

The form builder that will be utilized in the system and the data monitor both need improvement at this time. I want to exchange the data between the activity and UI basis. Currently, they are using a JSON file, which needs to be improved. We need something that can be used as a user interface and the user can make the data binding and exchange data between the activities.

This is what we did ourselves. We had the engine itself and we created a data monitor and formed it on top of it. This is what is missing in the system.

The initial setup can be complex for business users.

There occasionally be some bugs in the solution. 

The solution needs to offer more languages such as Chinese, Arabic, Hebrew, et cetera.

The system is stable. This is why we selected it. Based on other products, we've found the most appropriate results coming out from the Camunda BPM engine. It's very good.

There are occasionally a few bugs, however, we are quite capable of dealing with them.

Since we are using Camunda as a core solution, a core engine of our system, we are going to continue using it. I'm not willing to change it down the line. There's no plan for us to change it and we are not thinking about changing it. It has all functionalities and we are using about 50% of the engine itself in terms of its capability. We will continue to invest in utilizing all Camunda functionalities in the BPM engine.

In terms of technical support, we are using basic technical support as we are a technical organization. We are a software house. Our team is professional and they have experience in Java and private cloud technology. They are able to fix any issue. 

That said, there are certain bugs in Camunda. They are publishing information about them from time to time. We study the tool very carefully. Support from Camunda doesn't mean too much to us actually, as, in our organization, we have about 380 employees, and the majority of them are Java developers. We take the basic support to track the bugs only.

I also have some experience using Visio as business process management and ARIS as well as Bizagi.

We are partners of Software AG webMethods as an automation tool. We are using Mendix and OutSystems as a low-code solution. ARIS, webMethods, Mendix, and OutSystems are what we mainly use. 

You cannot compare Camunda with ARIS since ARIS is only for our documentation, business process documentation. You cannot compare it with Camunda. It is a totally different scope. However, in comparison between Mendix, OutSystems, and webMethods, they are very expensive tools and ultimately provide the same functionality, yet they are not using a pure BPMN XML. Maybe transferring the workflow between those systems doesn't work. That said, the consistency between, for example, Bonitasoft and Camunda and Bizagi is a matter of import and export. Between other systems such as webMethods and OutSystems and Mendix, for example, in webMethods, they are only still using an enhanced BPM engine mainly, meaning that they are not using the pure or the standard BPM notation. The same applies to Mendix and OutSystems.

The initial setup, for business users, is complex. If you compare it with cloud systems and Mendix, it is complicated. It has a very strong and very rigid back-end BPM engine and it's more trustworthy if XML files have been generated from Camunda. The quality of the XML file being generated from Camunda, the XML files of BPMN, is more trustworthy than other systems. That's why we selected it. This is the main reason that we selected it.

With the Camunda installer, the deployment of just the solution is pretty fast.

However, the automation process with the current functionality, meaning with the missing functionality of data monitor and data binding and with the lack of proper UI representation, it took us a year to develop those components to have a low-code solution on top of it.

Now, with our low-code solution on top, it will take us one to two days to have a visible process automated.

We are an integrator and we are consultants in business process management, and we are developing a tool on top of it. Therefore, we help our clients to implement. However, when we originally installed Camunda, we handled the process ourselves. The way we do things now, we try to make it easier for clients.

We are using a developer license. I can't speak to exactly how much we are paying, or exactly what license type that we are using. I'm not the technical lead or the solution delivery team. Therefore, I can't answer this question.

We did a lot of POCs on available products in the market, such as Bonitasoft, Camunda, Bizagi, so on. However, based on that POCs, we found that the best way to go forward in our solution in terms of the functionality and the accuracy of the XML files. If they could be generated by Camunda it can be more useful for us to adopt in our solution.

We are users of the solution.

We are the latest version due to the fact that we are developing our own product based on Camunda. We are developing a solution based on Camunda. We are a heavy user of Camunda.

Camunda is not so popular in the market due to the UI (meaning the form builder, the way of developing the forms which would be attached to the process), and the data monitor (how to exchange the data between the activities).

A company would need to create an integration framework between Camunda and other systems. If they sold their offering with the UI and data monitor it would be the biggest automation tool ever.

For us, with our experience with using the tool, you need a good developer to be able to use the system effectively. Other than that there are no issues. For an organization that wants to adopt Camunda, they need to have the proper resources, and the proper training to use the system. 

I'd rate the solution at an eight out of ten. There's a bug inside the BPMN monitor that knocks a few points off the rating. If the system is not saved, it will crash.

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

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

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

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

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

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

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

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

We have been using this solution for about one year.  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Primary use case is for fast prototyping innovatie processes within the social domain of the government.

Camunda has enabled us to do quick prototyping within end-to-end team consisting out  of information architects/process architects/developers and product owner to form a consistent view in business value, achitectural compliancy and technology.

The number of client implementations and cross-language capabilities to support multiple frameworks is very pluggable compared to other BPM engines out there. It's also more portable than most of them. Next to being open source, the modellers are made in HTML and can be embedded in your own website with little effort.

The user interface needs improvement. It should be more tailored to the end-user and offer a better user experience design over the user interface itself.

The solution could also use more and better frameworks in terms of embedding them in the engine. Right now the only embedded framework that's supported is Java. It's not a problem because you can also have remote workers that do part of the process through their remote RESTful API which they have clients for, but you cannot embed .NET. You cannot embed that for execution within the engine through delegates, so I would definitely say that would be a plus if they would expand that. Certainly in terms of performance.

I've been using the solution for two years.

I haven't had any issues with any instability.

There's a free version and an enterprise version, so it depends on which you choose but it's very scalable, but you have to understand it's persistence strategies as it uses a centralized database. That's normal for a BPM, however. In their new product Zeebe, which is a derivative of Camunda, they've made it completely decentralized and scalable via partitions, which might be more generic and easier to understand than the forementioned persistence strategies of Camunda. Because of partitioning, Zeebe is also a step forward into better orchestration in a micro service landscape. On the other hand that comes with the cost of complexity of installation. I would say for small to mid-size companies Camunda is scalable enough.

We're using it in the innovation field labs for the government so there's about potentially 350 municipalities there, and the number of people who are participating in this common ground field lab is about 150 potential developers, product owners, business analists that can be tied together in their disciplines around the Camunda Process and Decision Modelling Engines. A few products in those labs are now being developed using Camunda.

We are able to do everything from community support. Everything is well documented there. There has been no need to get support from them specifically but one of the owners writes a lot of papers and presents webinars which you can join for free. I would say they have very, very good support and are very open-source community-minded. I think they are one of the most supportive companies I've seen.

I don't have any knowledge about the paid support, because we don't do paid plans. I suppose that it would be great because if their free seminars and white papers are good, I suppose a higher level of support would be great, they really know what they are doing.

We used a workflow engine. The reason for switching is compliancy by design. Mainly Object Management Group (OMG) and Triple Crown Standards (BPMN, DMN, CMMN), which are supported by Camunda allowed us to reach this compliancy.

It depends on how you set it up. If you want to set it up for demo purposes or development and start working with the product, the set up is fast. The first one I installed took me five minutes and it was running.

We wanted an open source engine. Therefore we did not evaluate other engines such as Mendix, Pega.

We use the free version, the open-source version, but there is an Enterprise option. And the Enterprise version has heat maps so you can easily optimize complex processes on performance. You can easily see the hot spots that need to be scaled in a different manner in terms of hardware or improving your process flow.

I would definitely recommend the solution to anyone. At least for the short-term. They are currently shifting towards their new product, Zeebe. We are actually currently using it already in smaller labs on smaller projects, such as modelling process flow's and micro service orchestration driving front end ui's such as digital assistants. But there is not much difference between the two so, I would definitely advise anyone starting with a BPM, in general, to start with Camunda. I found Camunda really easy to start with.

I would rate this solution 8 out of 10.

We have integrated Camunda workflow and decision engine into our solution that enables management and digital sales of products – Digital Product Center. We use mainly Camunda Modeler and Camunda Cockpit. For some implementations, we also used Camunda Tasklist.

Camunda is used to model and orchestrate processes. We have developed a module where for selected process steps, the user can build forms that will be used to present or gather data by the end-user.

Another module is responsible for defining the products, with business parameters, that an end-user will be able to buy on the platform. The link between product definition and process definition is also configured.

This solution did improve our product significantly. We were able to focus on the development of other modules that integrate with Camunda, and together provide a powerful tool for our clients. Using such a solution gives our clients great flexibility and a short time to market for new product implementations. 

Next to our product, we are also using the Camunda workflow and decision engine in other custom implementations. Our partners can benefit from open-source, as we did with our product, and thanks to that, we get more custom development contracts.

It is very important for us to have an engine that understands the model defined in the modeler, according to BPMN 2.0. This way, we can use the model for business and development purposes without extra workload. We noticed that the project team collaboration is more effective when we use a working process model.

Last but not least I can mention robust and flexible Camunda Rest API Integration, the lightweight process engine can be easily distributed as a microservice, multiple database support, pluggable architecture, and bpmn.io.

In the future, I would definitely like to see the process administration (migration, audit, tracking) and process evaluation (optimize) features added to the community edition. Right now, thanks to the pluggable architecture, we have built features that partially substitute the enterprise edition features.

We have been using Camunda Community Edition for six years.

We didn’t have any problems with the Camunda Community Edition on production installations. We do have experience with process instance volumes starting in hundreds a year and up to 10 million a year.

The Camunda BPMN Platform is very flexible and gives several options to deploy and scale it. Process Engine can be deployed as:

• Embedded process engine – in your custom application (ex. Spring boot application)
• Shared – Camunda deployed in Application Server or Servlet Container (can be a Spring boot app)
• Standalone instance - it can be deployed as a microservice

These options give you a wide range of possibilities to scale your application. From horizontal scaling to vertical. Moreover, it can be deployed on-premises, cloud, or private cloud, including autoscaling mechanisms.

We did not use another similar solution but we did have experience with homegrown workflow engines, embedded in business applications.

The initial setup is straightforward, especially with Spring Boot Camunda Starter. The configuration is in application.yml files.

We have an in-house team for deployment and maintenance.

There is an open-source version available, that in its core features (workflow and decision engine, modeler) is exactly the same as in the enterprise version.

My advice is to think about what is most important to your business case and choose the right version. You can always migrate to Enterprise edition.

When we started to build Digital Product Center, we evaluated several options available at that time. We decided to use Camunda due to several reasons, but primarily due to the most valuable features mentioned above.

We are using the community edition so it is hard to ask for extra features ;-) I fully understand that if we still want to benefit from the open-source version, there has to be a paid premium version, so that the product can be further developed.

We had a client who wanted to use a BPM to track user subscriptions on their website. They had 20 steps from different areas and different people who wanted to join as new users of their services. 

We had to use Camunda BPM to track those services because they used to lose track of some clients in the past. They then had to spend more, add some more steps, and add new user subscriptions for months. 

The key here was always to track a new user and guarantee that they will get subscribed to their service in good time.

There's this graphic that tells you how many lines or how many tickets are in each step. In that way, you know where you stand. I find this feature very valuable.  

These are your bottlenecks, and you can see what the tasks are, the problems, see how much time must be spent on them. Then you can propose to fix it or make some improvements to make things go faster.

Documentation can be improved. Right now, the documentation isn't properly organized. We have a lot of documentation. We follow the instructions. We follow some blogs and videos on YouTube. But it doesn't feel like we have all the information we need to implement Camunda BPM.

I have been using Camunda BPM for two years.

Camunda BPM is a stable solution.

Camunda BPM is a scalable solution. It's a JAVA-based application, and we were able to install it in AWS and do all the things we wanted to do. 

The initial setup was complex. We really needed to study and understand how it worked. It was difficult because we didn't have enough information in the manuals.

We did what was said in the manual and then wanted to do more. We watched several videos, and we started to connect the dots. With our own solutions or conclusions, we were able to implement Camunda BPM.

We implemented Camunda BPM by ourselves, in-house. 

I think Camunda BPM can improve their licensing costs. It isn't easy to find clients with Camunda BPM licenses mainly because it's quite expensive. I think the license for an on-premise system is about $50,000, and that's expensive when you have only 100 users.

I used Bizagi before. It's easier to implement, but the problem is that you have to use their suite. You have to use their screen, their admin screens, or user screens. The UX and UI experience is also not good.

We decided to go with Camunda BPM because it gave us what we needed. That is, we can get inside Camunda and use only the tracker of the application. We don't need to use mandatory things like your pages or your web forms.

We can really code what we want and use it. We can create our own UI while using Camunda BPM at the same time. We really liked that because in my company specifically, we use a lot of UX, so all the UIs were very important for us.

Camunda BPM allows us to have a BPM bot with our own UI, and that's what we liked most about Camunda.

I would advise potential Camunda BPM customers to be patient. Perhaps all the information isn't available in one click, but it's possible to implement Camunda BPM, and it's quite flexible. It's worth a try.

On a scale from one to ten, I would give Camunda BPM an eight. 

I mainly use the solution for learning purposes.

I primarily use the solution in order to get a clear view of my customer, including what we are doing and what processes are being made making it easy to see everything that is happening.

Overall, the solution has been very solid.

The solution is very customizable.

We're currently using the community version, which is open-source and free to use.

The solution is stable.

For the short time I have with the tool, today, I can't see something that is missing as a product and its benefits. Maybe minor things that I haven't had the opportunity to notice yet, like an easy installation using Docker or scripts where you can see the functionality quickly.

I've been using the solution for about a month or so at this point. It's still quite new to me. 

The stability of the product is very good. There are no bugs or glitches. It doesn't crash or freeze. It's very reliable. 

We haven't really experimented with scalability at all. We haven't used it for very long. The process we are running now does not have a large volume. Our processing is not too high today. I didn't push the framework to see how it goes with big volume data.

Currently, we have only three people that are using it in the company.

We haven't used the solution for very long and therefore haven't really had a need to reach out to technical support. As I've never been in contact with them, I can't evaluate how useful or helpful they are.

I have looked at Bonita Software a little bit, however, I haven't gotten too far in terms of studying it.

The solution's initial setup has a medium level of difficulty. It's not as easy and it's not hard. Maybe someone who is starting out and doesn't have any experience with any other framework may get into some headaches. However, I've worked with it now and for my level of expertise, it's got a medium level of difficulty to set it up.

We're testing the solution still and therefore we are using the community version right now. I wanted to take a look at the enterprise version, however, my customer would like to see more value before they agree to get into it.

We're just customers and end-users. We're currently still experimenting with the product and learning about it.

I'm using the latest version of the solution. I cannot speak to the exact version number, however.

I'd advise users considering the solution to stick to the documentation and go to their GitHub to view some staples. There is a lot of good stuff in there.

So far, we have been happy with the product and its capabilities. I would rate it at a nine out of ten.

The primary use case is for modeling processes.

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

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

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

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

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

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

I have been using Camunda BPM for one year.

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

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

We have three users.

I haven't reached out to technical support.

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

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

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

The initial setup was straightforward.

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

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

It's free, open-source.

I use the open-source free version.

I reviewed Sygnavio and Pega Systems. 

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

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

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

I would rate this solution an eight out of ten.