SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I need to know Limitations of implementing InfoPath forms in SharePoint before I deploy it. Can someone please help me out?

share|improve this question
Limitations in regard to... ? – Nigel Whatling Jul 1 '12 at 6:27
I mean Disadvantages of InfoPath implementation. – neo269 Jul 1 '12 at 7:49
Uh, disadvantages of implementing forms in SharePoint compared to using the thick client? Limitations/disadvantages in security, performance, visual experience, ...?? What specifically are you concerned about? – Nigel Whatling Jul 1 '12 at 8:25
google it mate :) – Muhammad Raja Jul 1 '12 at 10:26
Due to the open ended question with mutiple answers, i have made Q comunity wiki – Anders Rask Jul 1 '12 at 20:31
up vote 1 down vote accepted

All Infopath disadvantages are counterparts or well-thought intentional Microsoft's architectural genial decisions.

For example, unavailability of Infopath template projects in Visual Studio 2010 is for common's good to leverage common platform and independence on versions of tools founded (or continued) by Infopath Designer 2010's VSTA restricted back to .NET 2.0 and Visual Studio 2005 Tools for Application


  • "Visual Studio 2010 does not include the InfoPath form template projects that were provided in previous versions of Visual Studio. You also cannot use Visual Studio 2010 to open or edit an InfoPath form template project that was created in a previous version of Visual Studio. However, you can open and edit an InfoPath form template project by using Visual Studio Tools for Applications"
    in msdn's InfoPath Solutions

  • "We want everybody who works with InfoPath 2010 to be able to leverage all three versions of our managed OM, the optimized design experience, and the best publish story from a single development environment that ships with Office; VSTA is that story"
    in comment-reply to msdn blog Microsoft InfoPath 2010

So, any disadvantage of Microsoft technology is just misunderstood or unappreciated genial and innovative advantage

If to speak seriously, the biggest disadvantahe, pitfall and trap of Infopath, amongst many, is that it is next-to-impossible to explain to your stake-holders (colleagues, customers, users, employer, web-developers et al) that Infopath forms are not web pages are not for developing web pages and Infopath Designer is not the developing tool for creating or modifying web pages

Infopath Designer is the tool for creating XML-based forms, i.e. XML data for forms and their content, which can be used by Sharepoint server as mostly uncontollable by developers add-ins for generating web parts and New/Create/Insert-Edit/Update/Modify-Display/View pop-ups/modes to web pages as very limited and mostly uncontrollable for development components while their most power and flexibility lie in client (non-browser-based) forms.

share|improve this answer

Like any tool, the solution should depend on the problem you are trying to solve.

I believe its root intention was for an electronic forms tool with templates that could be easily created by regular information workers, and not required to be developed by "programmers" who would do regular web forms in ASP.NET. I think its a great tool that definitely has some great uses.

Where it has perhaps come up short is end users hardly ever build forms. Instead they are built by either developers or developer-like people. The developers tend to come up with sophisticated solutions that may or may not be best suited for the technology. As an example, I have a pretty strict edict that says "never add managed code (.net) to an InfoPath form" since it complicates the deployment and management of that form with SharePoint. At the same time, many aren't so strict and do that.

Given a given problem, I work with my clients to find the right solution. Sometimes it is InfoPath, sometimes it is not. Within a given organization, there are likely reasons to use both approaches depending on the specific problem.

share|improve this answer
  • One limitation I had to deal with when working with IP forms was the limited set of controls. Compared to ASP.NET, the IP control are very limited. Many times I had to find work around. If you design the IP form to open up in the browser you will yet get more restrictions.
  • I also agree with @Mark that introducing code behind for the IP forms will complicate the maintenance and the deployment of the forms.

  • Since IP form development is different than ASP.NET forms, you need to learn it.

But, taking into account all the IP limitations, there are many situations were IP forms is the wise decision.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.