7 Reasons not to use InfoPath

Filed under: InfoPath 2010

Learn when it is appropriate to use InfoPath and when it is likely not a good choice.


You should not use InfoPath…

  1. Because InfoPath has been installed on your desktop computer, you are wondering what it is for, find it a pity that the application is not being used, so want to find ways to make use of it.
  2. When you want to fill out forms through a browser to submit data to a database, but don't have SharePoint installed and are not going to do anything with the XML produced by the InfoPath forms.
  3. When you want to replace ASP.NET forms with InfoPath forms, because you think it is easier to create InfoPath forms and repeating tables are cool. While a few scenarios may justify creating InfoPath forms, InfoPath forms are not suitable for all scenarios. You should consider each scenario individually before making a decision on whether InfoPath forms are suitable for your scenario or not.
  4. When you want to replace Access forms with InfoPath forms, because you think that rules are easier to work with than writing code. Remember that Access forms are native to Access and that InfoPath forms are not. So there will be times when you will have to find workarounds and/or write code in InfoPath too to be able to get things done within an Access database.
  5. When you are looking for a reporting tool and think that InfoPath fits the bill. InfoPath is not a reporting tool.
  6. When you want to use an InfoPath form to perform complex calculations. Performing calculations is not a forte of InfoPath. Excel might do a better job.
  7. Because I've told you to use InfoPath. You are a better judge of your scenarios than I am. This post contains my personal opinions and views and nothing else. Besides, who am I to tell you when to or not to use InfoPath?

So what are appropriate scenarios to use InfoPath? It is simple really…

Think about the workflow (route) a normal paper-based form (for example a passport renewal form) goes through and you'll have your answer. A paper-based form generally goes from person to person, or data is copied from the paper-based form and stored in a system where it then goes from system to system or from system to person. You can translate this same workflow to InfoPath forms. The only difference is that InfoPath forms start out being digital/electronic instead of paper-based.

So whenever you have a scenario where you want to make structural data (data that follows a predefined structure) shareable by allowing this data to go through a workflow that involves people and/or systems, you have a candidate scenario for using InfoPath.

And while InfoPath forms can be used as interfaces to applications or databases (for example workflow forms and SharePoint list forms can be seen as interface forms that just pass data onto to something else), you should think twice about your return on investment when trying to set up such solutions and ask yourself whether InfoPath is really the best option or whether another tool could/would do a better job. A good example of the latter is deciding whether to use InfoPath or ASP.NET forms as an interface to a SQL Server database.

The bottom-line is: Don't blindly use InfoPath just because it's there and/or relatively easy to use. Have a good reason to use it. Technology should not be used, because it's fun to do so; using it should make sense and serve a purpose.


Related Posts


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. 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.