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.
React is a JavaScript user interface construction library that works well for:
Developing web apps with dynamic and complicated user interfaces.
creating reusable UI elements that may be used in other applications.
creating single-page applications with dynamic content updates that don't require a page reload.
The Virtual DOM's effective updating mechanism allows it to handle large volumes of data updates.
React, on the other hand, might be less suitable for:
Websites that are simple, stagnant, and have no interaction. Other libraries or simple HTML, CSS, and JavaScript may be a better fit in such circumstances.
Web sockets may be a better choice for applications that need real-time updates, such as chat or gaming apps.
When creating mobile apps, React Native is a better option.
Server side rendering only, as React is designed to run on the client side.
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.
React is fantastic for building performant user interfaces. Our web app is snappy and great for our customers.
React has the philosophy of doing one thing and doing it well which is the view layer of the application. This makes it incredibly intuitive and flexible for developers to use.
React has lead the way in being able to write modular and structured code. It is a drastic improvement since the days of spaghetti jQuery code.
React has an unmatched community. The amount of tools and libraries available is fantastic, and there plenty of solutions available online for common problems.
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.
Debugging React is challenging. Bugs in react code generate stack traces internal to React and it is often totally unclear how it relates to the code you actually wrote.
Relating your React elements to corresponding DOM elements is difficult. The intentional separation of virtual and actual DOM also makes it difficult to map the elements to the structures in the DOM. This is partially ameliorated by the use of the React dev tool, which provides a DOM-like view of the React elements, but the tool still does not provide a direct correspondence with the DOM that is often necessary to figure out why something isn't right.
Because JSX is React-specific and not a language feature, a special compilation process is necessary to convert JSX code to normal JS. Coming from a C++ background, compiling things doesn't bother me, but many JS developers are used to a less structured development.
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.
React is just a bit of a different animal. I was avoiding it for the longest time. I thought for sure I would land on Vue or something else with a more approachable and familiar appearance. But after taking an online course in React, I started realize what people were raving about (and complaining about) and decided to implement it at our office for one of our products.
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.
Since it's open-source and very popular, the community support for React and related tools and libraries is excellent. There are a lot of people using the same tools, and so issues tend to get fixed quickly and "recipes" are easy to come by. And since it's backed by Facebook, they have a dedicated engineering team working on the progression of React.
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.
While this is a widely contested debate with various blog posts and benchmarks all over the place, its really a personal choice to determine what works for the team. Coming from a Angular 1.x background, I decided to try a new framework when Angular 2.x was announced and at that time React is gaining popularity and Vue hasn't taken off yet. Compared to Angular 1.x and Vue (hybrid of React and Angular) that split the logic from the html templates, I loved the way React breaks code into components using the jsx syntax. In my mind, this allows for cleaner components and easier maintenance
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.
