When is InfoPath Ever the Answer?

by · Published · Updated

Print PDF eBook

Since I’ve started working with SharePoint back in beta 2 of 2007, I’ve wondered what the infatuation with InfoPath is.

Everyone from enterprise architects and business users seems to be very intrigued by it.

As a more technical guy who’s had to dig into it, I find it a puzzling beast and really don’t understand why folks even give it a second whiff.

To understand why, let’s take a step back and examine the landscape of forms technologies which are available in the typical enterprise environment and how they fit into SharePoint.

Web Forms

  • Pros
    • Extremely flexible and powerful; a developer can create any form imaginable.
    • People are familiar with web forms because they use them: Every.  Single. Day.  When they log on to their gmail, when they buy something from Amazon, when they sign up for Facebook, when they log into The New York Times website — people use web forms every day.
    • Deploys fairly easily into a SharePoint environment using .wsps and can be permissioned like other SharePoint artifacts.
    • Easily understood by developers and easy to hire developers or contractors to manage; web forms developers are a dime a dozen.
    • Easy to integrate additional data into the forms since it’s easy to call out to web services, look up files in a file system, perform searches across SharePoint, etc. to incorporate additional data and intelligence into your forms.
  • Cons
    • Requires a developer to create and update the form.
    • Requires custom programming.
    • Not available on the desktop or offline.
    • Doesn’t work well for forms that need to also support print versions since it’s nearly impossible to create a printed layout that will 100% match the on screen layout.

Word Document Forms

  • Pros
    • Fairly flexible with a programming model that can be easily accessed by power users via record macro or custom written macros.  Can build fairly complex interactions.
    • Deploys easily into a SharePoint environment by simply uploading a document template to a list and associating it as the default template.
    • Quick Parts map fields directly onto content type fields on the list – save the document back to SharePoint, and the fields are updated in SharePoint.  Update fields in SharePoint and they are pushed down to the Word document.
    • Business users can create these easily.  In fact, if you asked someone in HR — for example — to create a form, more likely than not, they will create a Word or Excel based form.
    • Form can be completed offline and saved back to SharePoint.
    • Printed form is pretty much identical to electronic form.
    • Businesses already have large inventories of Word forms.
  • Cons
    • Macro programming isn’t accessible to most business users.
    • Macros may present a security risk.
    • Not as easy to perform complex tasks (for example, multiple web service calls) as it is in web forms.
    • No direct integration with the server environment and the SharePoint content store – may still need event receivers and what not to accomplish certain tasks.
    • Requires Word runtime on the desktop.

PDF Forms

  • Pros
    • Form is “locked down” once deployed.
    • Form is easy to build using Adobe Acrobat.
    • Printed form is identical to electronic form; create one form and use it everywhere.  This is especially useful in some cases in some industries like life sciences.
    • Everyone has Acrobat on their desktops.
    • Business users already have the skills to work with Adobe PDF forms and PDF forms can be easily created from Word forms.
    • Businesses already have large inventories of PDF forms.
  • Cons
    • Requires paid versions of Acrobat to create forms, but your business users probably already have these.
    • Requires some custom programming to expose the form fields to SharePoint (but easy to program and only needs to be done once); not supported out of the box.
    • Dynamic forms are difficult to create, requiring developers to write embedded Javascript or logic to build the form dynamically on the server before serving it.

InfoPath Forms

  • Pros
    • Microsoft really wants you to use it and thus they’ve rigged it into various points in SharePoint, Office, and SharePoint workflows (but you can do these with web forms, too).
    • Some forms can be used in the web or on the desktop.
    • Easy to build basic forms (but not as easy as it is to use Quick Parts in Word).
  • Cons
    • Requires license to InfoPath to create forms and your business users probably don’t have these.
    • If you ask a business user to create a form, the user will either: 1) create it in Word, 2) create it in Excel, 3) create it in PDF, 4) ask IT to create it.  No business user will instinctively think “Ah, I’ll create an InfoPath form”.  It’s not a technology easily leveraged by anyone but someone technical.  The idea that power users can create and own their forms is a myth; no business user wants to spend their week working on a form when they have hamsters in IT to do that for them.
    • With that said, it’s going to be a LOT easier to find developers who are strong in web forms (and they’ll probably be cheaper) than it is to find developers who are strong in InfoPath (and they’ll probably require higher rates).
    • While some forms can be used via Forms Server or on the desktop, the truth of the matter is that Forms Server enabled forms are limited to a subset of the desktop forms’ functionality.
    • InfoPath forms are difficult to work with programmatically compared to writing Word macros or ASP.NET web forms.
    • Anything beyond basic interactions will require programming anyways, so why not pick the technology that’s easier to program for?
    • Complex form fields (for example, repeating rows) don’t map to SharePoint fields and cannot be surfaced in SharePoint as metadata, making it somewhat less useful unless you’re willing to spend the effort to manually manage that serialization of data.  But then, why would you choose InfoPath and not Word or web or PDF forms?
    • Electronic forms are not identical to printed versions (as is required for some FDA forms which can be submitted electronically or as paper forms or as scanned versions of paper forms) so in some workflows, you’ll need to create separate forms for printed versions and consolidate that data manually.  If you need to create those printed forms in Word or PDF anyways, why bother creating InfoPath forms?
    • Difficult to share forms with users outside of your corporate firewall because: 1) they probably won’t have InfoPath on their desktop (but they will have or can easily get Acrobat or Word) or 2) you have to get them access to your network to serve them the form via Forms Server.  With Word based forms or PDF forms, you could theoretically just email the forms, collect them, and upload them — it gives you the flexibility to create these types of workflows.

Ultimately, I think InfoPath is a poor choice for forms because there are better options either from the perspective of developers or the perspective of a business user.  It’s a myth that InfoPath will allow business users to self service and easily create and customize their own forms and thus save time and money.  If anything, it’s even easier for business users to create their forms in Word, a tool they are already intimately familiar with.  Anything beyond the most basic of forms will require programming and IT involvement anyways and if that’s the case, why bother with InfoPath when it’s harder to resource for?

I don’t think I’ll ever understand the infatuation with InfoPath as a solution.  I do wonder if most folks are simply unaware of the Quick Parts functionality in Word 2007 and 2010 and how nicely it integrates with SharePoint.

You may also like...