Why Don’t You Use InfoPath?

I get asked this question a lot.

Hey Shereen, Why don’t you use InfoPath more often in your projects?

To which I often reply, it’s the 80/20 rule. InfoPath doesn’t get me all the way there, and to invest that much time and effort only to hit some project impeding roadblocks is not a conversation I like to have with our clients. It’s not fun, no one enjoys explaining why you CAN’T do something, because when it all boils down, clients are only interested in the solution.

Recently, however, I was given the opportunity to work with InfoPath again, and it’s reminded me in many ways, the pros and cons of using this tool. So I’ve jotted some notes down, and I’ll share with the rest of you, and if we can have a constructive, intelligent debate about this, I’m all for it. Keep in mind this is InfoPath 2007.

Let’s start with the Pros.

  1. It’s incredibly easy to do some basics in InfoPath. Adding controls to a page, validating those controls. Applying conditions that define when to show/hide specific content, or when to display that content in a different way. Tab order, submission and layout are all examples of things we can do well in InfoPath. This is something any power user can do, and probably do well.
  2. It makes it possible for power users to maintain a form post-development and well into the future. The same is not true for a custom form or web part built in ASP.NET I don’t care how ‘powerful‘ your users think they are.
  3. It’s definitely a bit easier to deal with Lookup columns and People or Group columns in the sense that it takes very little effort to wire them up and save/load from those controls within InfoPath. These are often problematic in standard ASP.NET form development.
  4. Repeating tables are great, these take little to no effort to add to the page and give users a lot of flexibility so that they may dynamically add or remove additional rows.

So definitely some good things we can do with InfoPath, however, there are definitely some pitfalls that make you go ‘ARRGHHHH‘!

  1. You can’t use a Contact Selector field and publish to a column of type Person or Group, you have to use either a workflow to populate these fields or custom code. A lot of times, we use these fields to power views with the [Me] keyword to display personalized views of the data. This is hard to do when a Contact Selector translates to a Single Line of Text. It also starts to challenge the Ease Of Administration principle I talked about above, because now users have to maintain a workflow or a section of custom code to get past this hurdle.
  2. In terms of order and organization of the Data Sources, it sucks. Any field that you create and then remove, does not get removed from the data source (which I understand), and you have to manually manage and maintain your data sources to keep it clean. I can honestly waste a ton of time formatting and moving fields into the appropriate containers and ensuring that overall, the data source stays clean. Maybe I’m just being anal, but it’s not something I particularly enjoy – I do feel it’s necessary though. It can get pretty hard to read if you have a form with 100 fields and you let it get out of control.
  3. It’s not easy adding expandable/collapsable regions. If you don’t agree, let’s throw up a challenge where you build out your regions in InfoPath and I’ll do it in html/css/jQuery and we’ll see who finishes first.
  4. Repeating tables only save the first row of data, not subsequent rows. So anytime you do use a repeating table, don’t plan on using that information for any views or filters of any kind. Normally though, this isn’t something I find myself needing to do often, but when it does come up, it’s kind of a pain that I can’t do it.
  5. Rich text formatting is not supported in browser based forms.
  6. There is no way that I know of to add a header and footer. If you’ve got a header or footer and multiple views, any change to those will have to be applied to each view. I’m not positive about this one, but if anyone corrects me on this, I’d be happy to update this post.
  7. If you are using any code in your InfoPath forms, you have to be careful with inconsistent or unsupported behaviour between the InfoPath client and browser enabled forms.
  8. March 30, 2012 – If you need to make changes to the name of a field in your InfoPath form, it more often than not, results in a loss of data for that particular field (if it’s being promoted as a column in SharePoint).


  1. When setting up tabbing between sections, it’s wise to setup a break in numbers in case it changes down the road. Otherwise imagine defining your tabbing order and then inserting a field at tab order 10.

So to summarize, I definitely see the power of InfoPath and if I can keep the requirements dead simple, and there’s flexibility when we hit roadblocks, I don’t see why this wouldn’t be the faster approach to form development. I’d probably recommend it.

However, if the reverse is true, and I know there will be business workflow or requirements that will make working with InfoPath a challenge, I’ll opt for the custom web form route, because that guarantees me no limitations to what I can do. And it’s likely faster.

It all comes down to an evaluation of the requirements and the prioritization of features over simplicity and maintainability that will ultimately guide which route I take.

If anyone would like to add to this, or has a suggestion for something I overlooked, ping me here or send me a tweet on twitter. I’m all for finding better and more efficient ways for getting things done.

6 Responses to “Why Don’t You Use InfoPath?”

  1. Jason Lochan January 23, 2012 at 5:49 pm #

    Thanks for having the nerve to say out loud what everyone who has ever dealt with InfoPath is thinking — I couldn’t agree more. I’ve had many clients go goo-goo over InfoPath not knowing how difficult their granular requirements will be to implement over it, when a simple custom web form could have saved them a ton of time and money.

    I hear the argument for enabling power users, but the same could be said of letting them customize in production with SharePoint designer to produce non-sustainable solutions, not because of the power user’s ability, but the SharePoint’s inability to allow the Power User to take SPD customizations and marry it to conventional SDLC (easily).

    When SharePoint reaches the stage of maturity where power users can make sustainable applicationsusing SPD, Workflows and InfoPath, then I think it gives more weight to this argument, but the truth is, it’s just not there yet right now for that argument to stand on it’s own in the SDLC.

    Just wanted to share my InfoPath black eye, and after many ‘ARRGHHHH‘! moments, I’ve come to accept that in 2010, the “seamless integration with managed meta-data”, is not so seamless.


    Thanks for sharing!

  2. shereen January 23, 2012 at 6:06 pm #

    Hi Jason,

    Excellent comment and thanks for contributing to the discussion. I try to tread carefully when it comes to making very strong opinions about any technology, because experience and wisdom take time, and there will always be moments where you learn something you didn’t think was possible or vice versa.

    Completely agree with respect to granular requirements, that’s a great way of putting it. I just can’t get over how difficult it is to do the simplest things. The other one I forgot to mention was being able to pre-populate the current user’s information on the form. I know you can do it in InfoPath, but as you’d mentioned, it’s not mature enough to make trivial things like that easy to do.

    Also, it’s probably worth mentioning that while the intention is to enable power users, I can tell you that 9 times of out 10, they get flustered using a tool like InfoPath and need my help anyways. But I suppose it makes the basics easy, like changing the validation on a field. Do you find that to be true also? What is your experience with users post InfoPath form deployment?

    Thanks for posting about the managed meta – that’s a huge bug in my mind and really helpful to know.

  3. Jason Lochan January 23, 2012 at 7:07 pm #

    After re-reading my post I can see how it can come off as hating on InfoPath and I think ‘non-sustainable’ is too strong of a term to use. Thank you — you are right it is a tool, and placed in the hand of the right person, in the right use case, can result in some powerful returns. I just haven’t been lucky enough to be part of that straight forward use case I guess.

    With the exception of one case, all of my InfoPath experience has been handed to me based on Power User’s using InfoPath Designer finding that they need code to solve a requirement that is too granular, or the sheer amount of work required in the Designer to achieve it. Funny enough, the main catalyst usually being pre-populating the people picker. I tend to try and leverage OOB field validations or Event Receivers for field validations, however there is always that case where they want conditional validation to occur based on information already entered or against external sources that always seem to demand VSTA, or prior to submitting any information.

    In the case of the managed meta-data, we were fully invested in the concept of it. Finding out there was no way to surface it in InfoPath was a shock. I had to write my own control leveraging SharePoint web services to account for that. The Managed Meta-Data service has it’s own administrative component that puts the power into the hands of the users, but in order to leverage it in InfoPath, BAM, you need a developer. It’s just never been that straight forward in my experience.

    My experience with users post-deployment has been centered around tweaking validations and look-and-feel. The painful part with validation iterations is knowing whether it needs to be implemented in the content type, the event receiver, or in the form itself, all the while keeping all of the other consumers of those artifacts in mind. It can be painful if the change is required in the content type, and explaining the ramifications of where the change is going to occur, and what it is going to impact, and the time required to implement and test that change has been half the battle.

    All of that being said, I’m looking forward to that use case where I can say I solved it in InfoPath in a painless way.

  4. shereen January 24, 2012 at 9:28 am #

    That’s a great way of putting it. I guess what it comes down to is the ‘oh crap, i can’t believe InfoPath can’t do that’ moment that we all try to avoid. The whole point of using the product, in my mind at least, is ease of use and maintainability of the solution, but that all starts to fall apart when I’ve got to insert custom code to deal with ‘the InfoPath can’t do that’ scenario.

    This latest project was an instance of a ‘successful’ InfoPath deployment because we kept the requirements dead simple. Any time we ran into a roadblock with InfoPath, we altered the business requirements to work.

    And I don’t think it came off as hating at all :) But you got it, right person, right use case, and it’s a great return.

  5. Kelvin January 25, 2012 at 3:16 pm #

    Can’t agree more with both of you. InfoPath is totally a love/hate thing with me.

    As one of those ‘small-d’ developers (I’m all about the no-code solutions), I saw InfoPath as a way to give our users a better, more intuitive way to enter data into a list. Being able to pre-populate fields from an external data source like a SP list or User Profile Service without having to rely on code?! Sign me up!!!

    … and then I tried to build out my solution. InfoPath isn’t a deployed application on our network, so I had to rely on InfoPath Forms Services to render out the form. I was prepared for the functionality trade-offs relying on IFS, but wasn’t prepared for the other concessions I had to eventually make like form formatting NIGHTMARES and a completely frustrating experience duplicating fields on the form I had to create; which, by the way, consisted of 10 different pages and about 350 fields. And don’t get me started on the issue of trying to jam data from a repeating table into a SP list. For something that should be seemingly simple, ended up being completely scrapped and done another way.

    Fortunately, as you said, I tried to keep things simple and gently ‘dissuade’ the client from certain functionality so I could keep it within InfoPath but unless I require pulling data from the User Profile Service, I prefer building out a new form within SPD. I feel like I’ve got much more control there, and don’t feel nearly as restricted as I do in InfoPath.

    Having said that, I’m quite proud of the final IFS product I released. I couldn’t have done it without InfoPath. I’m excited about what I’ve been reading regarding InfoPath Designer’s functionality within SP2010 (especially workflow form customization) but am still going to approach cautiously.

  6. shereen January 25, 2012 at 3:49 pm #

    Great comments Kelvin, I had the exact same issues recently with the repeating tables and had to re-architect a different approach with my client. what a bummer. i haven’t tried InfoPath 2010 as of yet, but having heard from Jason that Managed Meta Data isn’t support I can see that being a problem as most of our 2010 clients leverage meta data heavily.

    The trade off or compromising just don’t seem worth it in my mind, but I’m willing to be wrong on this one, as the alternative generally means a more flexible and maintainable framework for my clients.

Leave a Reply