What are the Benefits of using InfoPath forms in SharePoint?

Question

What are the Benefits of using InfoPath forms in SharePoint?

I’ve been doing research on InfoPath to see how it integrates with SharePoint. The idea of letting users create their own forms offers a lot of power, and could enable people to handle some of the small requests they have on their own. However, outside of creating a form library that is driven by an InfoPath form, InfoPath appears to quickly become a hassle and a hindrance. Sure you can build code to directly talk to the SharePoint Object Model, but then you can only seem to be able to run your forms in the browser.

If you’re going to run everything in the browser, why not just use an ASP.NET form?

Also, besides the basic forms library approach, what other benefits does InfoPath on SharePoint offer?

Answer 1

Here are a few benefits of InfoPath forms over ASP.Net forms.This will, of course, always depend on your mix of requirements, developers, user skill, etc.

• Forms are simple to create and modify for people familiar with MS Office
• They integrate directly with the metadata in Sharepoint, unlike an ASP.Net form
• Workflow Foundation is available through Sharepoint and simpler than using an ASP.Net form
• If you're dealing with document-based processes (like work orders, orders, permission requests), it might make more sense to have a repository of the documents, rather than building a reporting structure off the data entered through the ASP.Net form
• The documents are ready to be used by a process implemented in BizTalk
• The validation and logic are run on the client with no additional programming, many times giving a much better user experience than plain ASP.Net forms

Answer 2

I like to think of Infopath forms as being a great solution to the age old "form in a word doc" issue that companies have. It moves the task of creating and modifying forms closer to the people who care about the information.

There are tasks that are difficult to achieve in Infopath, but again it depends on the knowledge of the person creating the form more than the technology itself.

For forms that are complex and/or require large throughput, a straight ASP.NET form would be a better fit. As always it is about choosing the correct (cheapest total cost?) technology to solve a problem rather than shoehorning a solution from whatever is lying around. (i.e. I still don't know enough about InfoPath to make a decision easily all the time).