How Nintex Fits into the InfoPath Forms Puzzle
We get asked all the time whether Nintex Forms can replace InfoPath.
It’s the wrong question.
The right question is whether you can build Nintex apps that are equivalent (or superior) to what you could do with InfoPath.
Why We Don’t Want to Simply Replace InfoPath
InfoPath started out doing one thing very, very well. It let us design forms that users filled out as if they were desktop documents, yet servers and services could get to as structured XML data.
A web-based renderer appeared in SharePoint, which let InfoPath forms be used to edit list items, too, but it never quite scaled nor offered the same feature set as the desktop runtime. Moreover, feature after feature kept getting grafted on. And since it was defiantly “not a development tool”, things like deployability, versionability, understandability, and documentability were never adequately addressed.
It was also a standalone effort, and not terribly integrated with other tools. It was either not possible or too difficult to make it work with other tools, so users asked for more and more things to be done by the forms themselves.
Today, far too many InfoPath projects have the form responsible not just for data display/entry, but for data access logic, process logic, and user/group security – none of which it did well.
Over the years, it effectively became a “frankenproduct.”
We Believe in Multi-Tier Solutions
A good app has a presentation tier, a logic tier, and a data tier. Today, most Nintex apps handle these with Nintex Forms, Nintex Workflow, and SharePoint lists. You could use InfoPath, SharePoint Designer, and SharePoint lists, but they didn’t make that easy, and now two of those technologies are deprecated.
We put as much logic as possible in the workflow itself, including what we show to whom at which time, and what we want to get from them. It makes it easier to design, improve and, most importantly, understand.
Forms are for presenting users with information and asking them for decisions and other input. They have logic, but it’s not process logic: conditional formatting and display, validation logic, lookup logic – not decision and flow logic.
This approach lets us reuse the same process with more than one form. It allows us to modify the process without having to touch any forms. Moreover, it makes both the workflow and the form design easier to understand and a lot less busy.
Every Form is Hiding a Workflow
No one should collect data and do nothing with it.
The contents of a form are going to be sent somewhere, reviewed by someone, and acted on by someone else. They may be combined with other information along the way, too.
In a pre-digital world, we handled this by making forms big, with lots of sections, many of which were labelled “for office use only,” and attaching a routing slip to it. If you’re going to collect some data at one point, move it along to someone else to make decisions, move it further along to yet another person, etc. – that’s a workflow.
The Obvious – But Wrong – Way to Go Digital
I’ve seen people, when starting with a large paper form meant to be passed around to multiple people, opt to turn it into a single electronic form.
They then spend all their time adding rules, views, or even code to ensure that different users see different parts of the form, that fields become read-only when the wrong person opens it, that the form changes itself as different people complete different sections. That form becomes a testing nightmare, a maintenance nightmare and, with all of that extra logic, a performance nightmare.
Oh, and since everyone needs to go to the same form to add input, everyone needs to have real-time connectivity to and permissions for the form’s SharePoint site.
The Right Way to Go Digital
How about breaking that form up into its discrete sections — and making each one of them its own form? Let the initial form start a workflow and have tasks present participants with the other forms as needed. Let a workflow determine which step-specific forms need to be given to which person at which times. Also let the workflow gather the input from all of those forms and do something with it.
Nintex Forms is optimized for this kind of work. We even think this is how you should use InfoPath if you continue to use it for several more years.
- Each form is easy to create/modify. They’ll still have validation and conditional formatting logic, but that’s still pretty lightweight.
- Those simple forms are faster. Fewer things to load and process before showing the form to the user.
- There’s no need to keep modifying permissions on a single form as it’s “passed” from user to user, because the different forms are connected to different tasks assigned to different users; the tasks are already user-specific.
- It’s much easier to design and visualize the logic in a graphical workflow than embedded in form instructions.
- We can manage the workflow and the forms associated with it as a set. Version them as a set. Approve them as a set. Deploy them as a set.
- Most importantly, each participant in the process gets a form that’s easier to use. It will contain exactly what’s needed for what’s being asked of them at that moment – and nothing else.
- Also importantly, they can get the form the way they want it; in a browser, in a mobile app, and even via email. Their input will be returned to the workflow.
We’re big proponent of this approach, and our technology is weighted toward making this kind of app easy.
Nintex is a workflow company. We provide forms technology of our own and work with forms technology from other companies, too. Our forms are what you’d expect from a workflow company: great user interfaces for steps in a business process.
And again, since behind every form you’ll find a process, we – and our legion of partners and customers – think it’s a quicker, easier, and happier way to replace “frankenforms” from any vendor.
Click here to try the Nintex Workflow Platform today!