If you’re bringing anything into Salesforce you should just invest now into Mule, you will get your money’s worth and find a myriad of uses to build APIs between many other systems. Once you build a component you can easily reuse it as a building block to attach to another source/destination. This makes it easy to ramp up quickly and spread usage of Mule throughout your enterprise. A good value for medium to large companies, but probably cheaper to outsource your job to a consulting firm if you are smaller.
We use Nintex to automate fundraising outreach at scale. It helps us send personalized emails to a large contact list, and we’d also like to automate follow-ups when there’s no reply. If you need highly customized solutions or clean, fully controllable code, I wouldn’t recommend Nintex. It has many features, but it’s not the same as building your own system from scratch. That said, it can save a lot of time for standard automation workflows.
It is best suited for Rest API development. Mule ESB uses RAML as an API descriptor which is less complex and easy to understand. RAML is an open standard majorly supported by Mulesoft. Once RAML is developed, it is very easy (a few clicks)to create flows corresponding to the resources defined in the RAML. One can also include JSON schema validation in RAML, and with the use of APIkit router, Mule ESB makes the request validation very easy (it's automatic basically.)
Mule ESB comes with a large spectrum of community and enterprise connectors. We have connectors for all the major platforms like Facebook, Twitter, Salesforce, SAP, etc. This enables Mule ESB to integrate with the other systems in a faster and more robust way. Mule ESB has many components to fulfill the requirements of each integration (for example batch processing, parallel processing, choice, etc.)
Mule API gateway is one of the best tools (modules) of Mulesoft's offering. It supports API governance and management very well. One can easily enforce policies on their APIs with API gateway. It enables some of the must-have features in an API solution (i.e. throttling, oAuth, access levels, etc.)
Implementing a CI/CD (DevOps) environment for Mule ESB is a very easy task. Mule majorly uses MAVEN as its build tool, which in turn makes it best suitable for CI/CD approach. Mule also provides MAVEN plugins for auto deployments to the servers. Mule also has a best Unit testing module which is MUnit. MUnit can be used for both Unit and Functional testing, and it is easy to write and generates coverage reports in various formats.
Integrations with other services using various secure authentication methods, along with the seamless integration with SharePoint, are the icing on the cake. This makes it superior to other BPM tools available in the market.
Flexibility in application development - The diverse configurable properties offer multiple ways to utilise the controls and events, affording the flexibility to expand your scope and enabling the creation and use of processes in a myriad of ways.
The streamlined and efficient deployment process significantly accelerates release management, allowing for faster and smoother implementation of updates and new features.
The user interface of the pages offers a more refined and appealing look and feel compared to most other BPM tools.
If you are creating a process with parallel subprocesses, there's no way to see, in a single view in Nintex, all the steps for the subprocesses. You have to view each sub-process in its own view, so it's hard to see what's going on at a high level.
There isn't an easy way to filter the processes by another user (not yourself) in Nintex. There is a report that shows processes and objects by user, but that's not as convenient. This is something that I've seen in other tools (OpenPages by IBM) so I am surprised that it is missing.
Nintex doesn't really have a way to capture iterative processes (which we have a lot of). It's designed for linear processes.
We are currently investigating which collaboration platform best suits our needs. Chances are that we move to SharePoint Online and then we're going to also consider the microsoft power platform (power automate and power apps) to develop forms and workflows. Aspecially the pricing model for the cloud is currently a blocking factor to go for the Nintex solution in the Cloud.
Based on the on-prem experience with this tool, I believe that they have a lot of potential to help the online version catch up to where the on-prem left off. Nintex developed their online version and it is not as fully formed or capable compared to the on-prem version, and the licensing model scales back what we would have liked to be an expansion or at least continuous improvement of existing flows. It is also not near as user friendly specifically to non-developers and has an uncanny similarity to Microsoft Flow in the online instance. Consistent with my reviews of the tool - I believe they have some good approaches to design thinking that, if translated well from on-prem to online, could make this a clear winner again.
The Nintex Process Platform has never crashed or had any availability issues during my usage. However there was an issue that was of my own making that caused a slowdown of the system. I had set up a process to run once a day and check for employees on a list that had certain parameters selected, and for some reason that I had to troubleshoot, the process instead ran constantly, which filled the cache quickly. I ended up having to dismantle that process so the system didn't crash.
Unlike any other process automation product out there. Not only is it a low-code, easy to use tool for building processes in environments like SharePoint or Salesforce, they have really started to expand their tool-set by offering tools to manage other things like process mapping, RPA, mobile,etc.
The support team works as fast as they can and they are usually fast to solver the issues. Sometimes they need more time to solve one of them because our workflows and so on are more complex than usual clients.
I used the Nintex training software, it was easy to watch and follow along. It didn't go too fast and was descriptive enough to understand what the steps needed were in order to produce efficient workflows and user friendly forms.
1.Start with Simple Workflows: Begin with basic workflows to gain user confidence before tackling complex processes. 2.Involve Stakeholders Early: Engage business users and IT early to align workflows with real business needs. 3.Comprehensive Training: Invest in user training to ensure smooth adoption and reduce resistance. 4.Leverage Prebuilt Templates: Use Nintex’s templates to speed up implementation and maintain consistency. 5.Iterate and Optimize: Continuously improve workflows based on user feedback and performance metrics.
Microsoft environment does not have the scalability of Nintex; it is perfect for small and medium-sized companies, especially in environments where Microsoft environment is almost entirely used. Although Microsoft offers options to connect to other applications, its platform lacks the development and robustness that Nintex provides. Nintex not only covers Microsoft environments but also Google and other important platforms.
The scalability is really bottlenecked by the imagination of the user. I was able to make processes for my own personal usage, making my daily tasks easier. I was also able to make processes that affected hundreds of employees, making large standardization and efficiency gains. So either way, the system is used the same way, and I was the limiting factor.
People have woken up to the amount of overlap after mapping their processes.
People can be resistant to process changes. You need to have the support from above or support from the 'business' that you are process changing to be able to see the positive impacts.
Numbers talk. if you can get a general salary figure from your HR dept to show savings for 'employee bands', then when you present reports, they will be all the richer in data.
