To use or not to use InfoPath 2013 in SharePoint 2013?
Read my personal opinion about whether you should continue using InfoPath or not despite Microsoft's decision to stop developing it and having it be part of SharePoint in the form of InfoPath Forms Services.
First I'd like to say that everything I write here is my opinion and my opinion only. I don't work for Microsoft and I have not had communications with Microsoft about InfoPath 2013. People have asked me for my opinion, so I am just giving it.
InfoPath saves time. And in business, time means money. But as you may have already heard, InfoPath is going away; there won't be another version after InfoPath 2013.
So what does this mean?
I'm very practical and simple when it comes to technology - or anything else for that matter.
Here. Let me break this down for you...
The first thing you need to know is where InfoPath might pop up in your company. That is, where and how are InfoPath forms being used?
InfoPath forms come in several flavors, many of which are listed immediately on the New tab when you open InfoPath Designer. The one flavor that is not listed is the workflow form.
So to keep things simple, you can use InfoPath to create:
- Forms to maintain data in SharePoint lists.
- Forms to create XML files.
- Forms to fill out document properties in Office documents.
- Forms to pass data to workflows.
- Forms that serve as interfaces to databases, web services, etc.
If you are using forms from the first category, your data is already in SharePoint, so there is no reason to panic.
If you are using forms from the second category, your data is being stored in XML files, which you can easily - okay, sometimes you might have to write code or use a bespoke utility - import into other systems, whether it be SharePoint, SQL Server, Access, Excel, or something else. So again, there is no reason to panic.
Document properties in Office documents can be filled out through Office applications themselves, so you can easily discard InfoPath forms there.
For workflow forms, you would unfortunately have to find another software solution that will give you similar functionality or build your own forms. I think a third-party solution may be applicable here and some research on your part would be necessary.
Forms that are being used as an interface would have to be replaced by other types of forms such as for example ASP.NET forms. You would have to write code for this or again find a third-party solution.
In the meantime, Microsoft announced that they would come up with alternatives and provide ways to migrate InfoPath forms. You can keep an eye out for that if you are worried about what's to come.
Data is at the core of any business, so all you have to think about is how you can get to your data once InfoPath is gone. And if your company is planning on staying on SharePoint 2010 or SharePoint 2013 (on premises) for a couple of years, there is no reason to be panicking at all, or looking for something to replace InfoPath right at this very moment. But if you are using SharePoint Online, it's an entirely different story...
As I see it, anything you build today, you are building to use in the immediate future - today, tomorrow, next month, etc. Technology evolves too fast for comfort. And anything that is currently working in SharePoint, is NOT guaranteed to work in a newer version of SharePoint. This includes third-party solutions.
So unless you are building something that is completely independent of SharePoint, there is no use building for the (far) future.
InfoPath is still here today and will be supported by Microsoft until 2023. I'd say, use InfoPath if you need to create something simple and quick. Why? Simply because most of the time it is easy to do and does not require you to write code. In addition, InfoPath provides functionality that any current and/or future rival will have a hard time matching.
However, try to avoid writing functionality in code as much as you can. This is not logic talking here, it's foresight looking at where Microsoft is heading with SharePoint. But then again, if you are staying on SharePoint 2010 or SharePoint 2013 for a while, there is no need to avoid code. And if you want your code to live across SharePoint versions, try making it as independent of SharePoint as possible.
And finally, if you are someone who needs to think about the future - architects do that sometimes - avoid putting InfoPath in your architectural design document, because InfoPath does not have a future.
So there you go. Practical, simple, and to the point, I hope?
P.S. BizSupportOnline will remain online as long as I'm still alive and can financially afford to keep the site online, so you'll still have InfoPath information/knowledge at your fingertips 24/7. And if the site happens to disappear, much of my InfoPath knowledge has been recorded in my InfoPath books, which will hopefully outlive me. And if I happen to find more InfoPath/SharePoint solutions that I think might be useful to you, I'll continue to share them with you here on the site or in the InfoPath Cookbook Clubs.
Copyright: This article may not be used on web sites (whether personal or otherwise), copied, disseminated, altered, printed, published, broadcasted, or reproduced in any way without an expressed written consent of S.Y.M. Wong-A-Ton. The techniques demonstrated in this article may be used within any Microsoft InfoPath project. This article is provided without any warranties. Copyright for this article is non-transferrable and remains with the author, S.Y.M. Wong-A-Ton.