A discussion about replacing InfoPath with another forms technology in SharePoint world seems to warm up the in last days, what is probably fueled by Microsoft’s announcement of general availability for PowerApps and Flow. And, while there are many factors which determine if a product will be suitable for this purpose (one size does *not* fit all), I would like to take a short look here at key InfoPath features and use cases, their importance, and the ways how they can be replaced.

I will compare (and, yes, show how to migrate) those features with our (skybow’s) own RichForms, since it is only appropriate for me to talk about our own tech. Certainly, this kind of analysis can, and should, be done for any competing product or technology, and the decisions should be made according to that analyis.

We loved InfoPath

We really did, most of the time. It is easy now to trash-talk it, but it is not fair. Even I, as a “hard-core” developer (whatever that would mean, but that is how I was called numerous times), who has worked with InfoPath basically only through its code-behind, had to admit that is was very suitable for many scenarios.

Easy to use forms designer

Regardless if we were creating simple list forms, or if we used SharePoint Forms Services to create complex input masks, InfoPath designer was – for the most of the times – doing its job decently. It was fairly simple to create good looking forms and to create simple field behaviors, even for the people who were not professional developers. By using repeating tables and repeating sections, we could easy create master-detail relations in our forms. It kind of just worked.

Validation and calculation

Field calculation and field and form validation were relatively simple to configure with InfoPath. True, that covered only the simple calculation and validation rules, but those were enough for a good portion of cases. Those rules, and expressions behind them, were easy to master for non-developers.

Code behind

And when all that was not enough, you would double-click a control, and Visual Studio would start, and you could pull the C# magic. You had access to form controls, to their events and their behaviors, and most of the time you could code it all down to the smallest detail. You had access to Microsoft.SharePoint namespace… you get the idea. You had the tools to get the job done.

And we hated it in the same time

Yes, the InfoPath Haters Club was a thing from the very beginning. And there were also good and valid reasons for it.

It is proprietary technology

It was not a problem as such that it was proprietary, but that it was often a big mess to set it up, and to get the things going. SharePoint Forms Services, InfoPath designer, browser rendering, whole deployment hell, especially with SharePoint Online… we all got our gray hairs with it. We did.

Only simple forms with SharePoint lists and libraries…

Yep, only the basics for SharePoint list forms were possible. One-dimensional, flat forms, without master-detail relations there, nothing complex, nothing fancy, nada…

…and the damned forms libraries for everything else

Now this was my favorite. Setting up Forms Libraries, where your data would actually be stored as a bunch of XML files, but some of it could be propagated to the list metadata, in order to be indexed/searchable. Well, this was… suboptimal. Working with the actual data, outside of InfoPath forms that is, became a nightmare, and was often impossible. I’ve seen a number of “InfoPath projects” which were completed to, let’s say 70-80%, and then rolled back because the last 20% was simply not possible.

Validation and calculation

Wait, didn’t we have this one in the “we loved it” list? Yes, we did, but we also said that only the simplest validation and calculation could be done with that one. For everything slightly more complex, Visual Studio was our only choice. And this was the point where you kissed your Power Users goodbye.

Code behind

OK, now – we definitely did have this one on the positives list! Yes, we did. But, since SharePoint 2010, InfoPath forms with code behind were deployed as sandboxed solutions. Well, that got deprecated pretty fast, didn’t it? In SharePoint Online (Office 365) it doesn’t even work anymore. Thousands of dead InfoPath forms with deprecated code-behind are floating through the cloud nirvana as we speak.

Disconnected from SharePoint context

Wait, what? But, yes, this is true. InfoPath was *not* solely a SharePoint tool! That means that you couldn’t that easily control the behavior of your forms, based on SharePoint context (current user, list info, etc). Yes, all that could be achieved with code behind, but it was not that straightforward.

Let’s talk about replacement

So, this was the good, the bad and the ugly talk about InfoPath. Let’s try to slice it, and to identify core features it provided, and then let’s see if those features could be replaced with an equivalent technology. While doing that, you should prioritize the importance of InfoPath features according to your requirements. For purposes of this article, I will use the 1-5 stars rating here, based on the requirements of my last InfoPath. You will, of course, do your own prioritization.

#	Feature	Priority
1	SharePoint native (no 3rd party technology has to be installed on the clients)	5
2	Integrated security (no additional security layer, or unauthorized data sources should be allowed)	5
3	Powerful UI designer	5
4	Master-detail relations, and managing multiple lists and libraries inside a form	4
5	Field behaviors, calculation, validation	5
6	Code Behind (for complex calculations and from behaviors)	4
7	Acting on data changes	3
8	Custom form controls and actions (adding custom buttons with actions, and form loading actions)	3
9	Easy deployment	5

With this, we have established an InfoPath-replacement check list, against which you need to check potential replacement technology. Do you go down the PowerApps road, or you look at the 3rd party technologies if PowerApps do not meet above-mentioned criteria, is a decision you need to make after systematizing your requirements and defining your priorities.