Replacing InfoPath in SharePoint – Do It Yourself!

So, I’ve been hanging out a bit in the SharePoint subreddit and I was asked what companies do if they need custom forms and cannot do custom development.

The normal answer would be to use InfoPath, but let’s face it, even with a very sympathetic sales rep, you’re still looking at thousands of dollars in license fees alone, not to mention that you’d still need to develop, test, and maintain those forms.

There are some third party alternatives like Nintex Forms, but it is still going to be thousands of dollars worth of licenses. The free and open-source alternatives I’ve seen haven’t impressed me so far.

I’ve made it a goal for 2013 to get developers to think more about the user experience of their solutions. The default user experience, especially when working with form data, leaves a lot to be desired, which is probably why InfoPath was so popular.

Your Wet Dream Come True!

Building custom forms in SharePoint shouldn’t be hard, though. In my SPInvoice solution, I have a form that looks like an invoice, with support for adding invoice rows and all, and it took me less than a day to get it running, and that included having to learn a bit about SPServices and JavaScript.

The method used in SPInvoice, though, isn’t complicated even if the results are stunning. In fact, give me a few minutes of your time to show you this video, and you’ll see what I mean.

In SPInvoice, I’m using far more complex techniques to accomplish some goals that may not be required for most forms. The underlying technique of getting the form to work, however, doesn’t need custom WSP development at all. It does require HTML, a bit of JavaScript including jQuery and SPServices, and you’ll need to setup a content type and a list to hold the submitted form data.

All of the techniques shown here rely on SharePoint Designer and a bit of know-how only; no custom development, no external dependencies, no programming required (unless you count copy-pasting some jQuery code programming).

For any PDF form, for example, or Word, or other applications that produce forms, you should be able to convert those forms into HTML using their respective applications and then tweak the HTML code to make it work with this method.

In fact, I’ll claim that with a bit of HTML5 know-how, you could easily replace a lot of the InfoPath functionality, and have the benefit of saving thousands of dollars and be able to put your forms on the public web if you so desire, even on a completely separate web server running your favorite brand of OS. With that, you can add nifty jQuery UI features or other web frameworks to your heart’s content. No longer are you limited by what the damned SharePoint Designer Design View can or cannot do.

Want to know the best part? This works in all version of SharePoint, from 2007 through 2013, because, well, it’s just HTML and JavaScript.

No stupid App framework to get in your way either… You can host your forms anywhere, set up SPServices to connect to your SharePoint backend, and viola, you have separated your web front end from the limitations of SharePoint.

Who said you couldn’t do SharePoint 2007 development on Linux?

Here’s the video, feel very free to post comments, questions, and so on below.

Oh, and here’s the sample code, but I must stress that this code is far from optimal so use it to learn, not in production.

.b

Found this article valuable? Want to show your appreciation? Here are some options:

a) Click on the banners anywhere on the site to visit my blog's sponsors. They are all hand-picked and are selected based on providing great products and services to the SharePoint community.

b) Donate Bitcoins! I love Bitcoins, and you can donate if you'd like by clicking the button below.
Donate Bitcoins

c) Spread the word! Below, you should find links to sharing this article on your favorite social media sites. I'm an attention junkie, so sharing is caring in my book!

Post Author

This post was written by who has written 424 posts on Furuknap's SharePoint Corner.

I do SharePoint. When I'm not doing SharePoint, I sleep, and then I dream about SharePoint. Oh, and I dabble a bit in cryptocurrencies (Bitcoin, Litecoin, etc)

18 Responses to “Replacing InfoPath in SharePoint – Do It Yourself!”

  1. Gene Vangampelaere
    Twitter: vangampelaere
    May 14, 2013 at 8:41 am #

    Bjorn,
    This is a really nice solution but can it replace infopath? What about displaying external (SQL) data on your form? That is more a challenge in JavaScript than it is in Infopath.

    • Bjørn Furuknap
      Twitter: furuknap
      May 14, 2013 at 8:45 am #

      That really depends, Gene, as always :-) If that data is exposed through a web service, for example, the situation will be no different than for any other page. If the code runs on the server only, nothing prevents you from adding code to the ASPX to connect to that data, but that’s beyond the “how can I get a reasonably looking form on my SharePoint server” idea behind the article.

  2. Ulrich Bojko
    Twitter: ulrichbojko
    May 14, 2013 at 10:47 am #

    Hi Bjørn
    Nice way of doing things. I like the simple approach. I’m tinkering with a way to use the same method, just for a newslist. How would you go about just displaying the elements ind the list. I have images, and RTF-text etc. Would you still hold all that in an input type or can I use another way?

    • Bjørn Furuknap
      Twitter: furuknap
      May 14, 2013 at 10:48 am #

      Well, like I said, I don’t really know anything about the HTML and JavaScript stuff, so I’ll have to ask you to ask someone else.

      Perhaps some kind commenter can help?

  3. Scott Brickey May 14, 2013 at 3:02 pm #

    I would be cautious advertising things like running your code on non-sharepoint sites (or “on linux”)… there are a lot of considerations to take into account, many of which have already been discussed on their site.

    Can it be made to work? perhaps… but advertising it as “sure, it’s simple” is beyond stretching the truth.

    some links for reference:
    http://spservices.codeplex.com/workitem/10025 (security concerns about cross site scripting)
    http://spservices.codeplex.com/discussions/357550 (concerns about topology, authentication, etc)

    • Bjørn Furuknap
      Twitter: furuknap
      May 14, 2013 at 10:34 pm #

      Security is always a concern and if one does not understand how to set up a site to support working into SharePoint or accepting data from outside SharePoint, then obviously one should not attempt to do so in public.

      Keep in mind, all of this happens on the client side. In other words, if this was a security concern for SharePoint, it would be a massive disaster because anyone can put such an HTML page anywhere and point it to any SharePoint server that is publicly exposed. Nothing prevents anyone from downloading the source code from this article and point it to http://sharepoint.microsoft.com/. That does _not_ represent any security issue at all.

      The point here is that where you host your HTML+JS is of no concern to SharePoint; the fact that the video shows this hosted in a SharePoint site is just a convenience and I could just as easily have hosted this on a server running on Linux or anywhere else, for that matter. It would require slight adjustments to the SPServices calls, but that’s still done client-side and can thus not represent a security concern for SharePoint.

      .b

  4. Tom June 18, 2013 at 6:41 pm #

    Can SPInvoice be done such that the data is saved into a SQL server database?? Where is the data saved, generally?? What is generally possible herein?? Can the forms created this way have workflows?? Thank you, Tom

    • Bjørn Furuknap
      Twitter: furuknap
      June 19, 2013 at 8:08 am #

      Tom,

      The data remains in SharePoint, and I’m not really sure why you would want to export it to a different database? SharePoint already is a database. What you are proposing doesn’t require SharePoint at all, so it would be a moot point to attempt to do there :-)

      To answer your question, yes of course you can have a web page send data to a SQL server database.

      .b

  5. Tom June 18, 2013 at 6:50 pm #

    P.S. I don’t require huge specifics, I’m just asking for general information…I do see the value in this approach and want to know more about what and where the data is so I can do a test/demo sort of thing where I work…I’m getting a server ready!! :) :)

  6. Chris June 19, 2013 at 1:49 pm #

    Interesting solution. I have been wrestling with InfoPath recently, attempting to make accessible forms without much luck, which eventually landed me here.

    My question is whether this solution is viable for public facing website forms? Ideally this form could be dropped onto a branded publishing page for anonymous use.

    Also, you made a remark about the impending death of InfoPath. Is this just an opinion or is there more to that story? InfoPath is a clunky beast but I can’t see MS letting it die so easily.

    • Bjørn Furuknap
      Twitter: furuknap
      June 19, 2013 at 4:26 pm #

      Chris,

      This type of solution could easily be put online on a public facing page, yes, and you’d avoid all the usual hassle of licensing and configuration. There are caveats to this, and you’d need to carefully think about security, and you would also need to make some changes to the SPServices code (to include web URL if nothing else). Beyond that, you should be golden.

      As for InfoPath’s demise, there’s no official word yet, but there seems to be a concensus in the community that InfoPath looks like it’s heading the way of the dodo.

      .b

  7. Jens June 20, 2013 at 4:04 pm #

    Hi Bjørn,
    nice way to build dialogs without InfoPath.
    I’ve tested your example and everything runs fine.
    But now I change the Leads-Contenttype angainst a Calendar-Item-Contenttype.

    By opening the aspx-Form to edit some values, all Inputfields are empty.
    When I put in some values and close the form the values are saved corectly to the list.

    You have any ideas, why are the Inputfields are empty while opening the form?

    J.

  8. Tom June 21, 2013 at 8:51 pm #

    There’s many reasons why one might want the data to go into another database.
    For example, a purchase request form should store the data for later import into an accounting software after an appropriate method was devised for doing so.
    One might want leave requests to work with one’s HR application, etc.
    Thank you, Tom

    • Bjørn Furuknap
      Twitter: furuknap
      June 21, 2013 at 8:52 pm #

      Sure, but I would think that would be better solved by letting SharePoint handle the transfer to the external systems and not do it client-side.

      .b

  9. Alv1s June 27, 2013 at 1:33 pm #

    Where are new entries? :)

    • Bjørn Furuknap
      Twitter: furuknap
      June 27, 2013 at 5:43 pm #

      Not sure I understand your question. The new entries are in the list where you create them. If you want a different interface for this, it’s possible using a similar method to build an improved ‘control panel’ or something like that where you can create new entries much easier than using the default SharePoint user experience.

      .b

  10. Venugopal Reddy September 5, 2013 at 2:06 am #

    Can we create People Picker using the SP Services??

  11. po April 14, 2014 at 7:36 pm #

    Brilliant.
    This is going to simplify my forms site new version as I won’t have to manually update aspx in the obscure sharepoint designer 2013.
    Thanks a lot for sharing.

    -PO

Leave a Reply