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.


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.

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!

Pin It

Published by

Bjørn Furuknap

I previously did SharePoint. These days, I try new things to see where I can find the passion. If you have great ideas, cool projects, or is in general an awesome person, get in touch and we might find out together.

22 thoughts on “Replacing InfoPath in SharePoint – Do It Yourself!”

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

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

    1. 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. 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: (security concerns about cross site scripting) (concerns about topology, authentication, etc)

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


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

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


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

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


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


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

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


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


  10. I updated your form.js code so it is more usable when there are multiple items in the list. I am using jQuery 2.1.3 and spservices 2014.02 on SharePoint 2013.

    here is the change:

    var listName = “Leads”;

    $(document).ready(function () {

    $(document).on(‘blur’, “input,select”, function (event) {
    // We want to update some list items
    operation: “UpdateListItems”,
    async: false,
    batchCmd: “Update”,
    listName: listName,
    ID: $().SPServices.SPGetQueryString()[“ID”],
    valuepairs: [
    [$(this).attr(“name”), $(this).val()]
    // When we’re done, do the same addition of HTML
    completefunc: function (xData, Status) {

    function updateAll() {
    var listItems = new Array(),
    fieldNames = new Array(),
    contentTypeIdValue = $().SPServices.SPGetQueryString()[“ContentTypeId”],
    j = 0;

    operation: “GetListContentType”,
    async: false,
    listName: listName,
    contentTypeId: contentTypeIdValue,
    completefunc: function (xdata, status) {
    $(xdata.responseXML).find(“ContentType”).each(function() {
    if ($(this).attr(“ID”) == contentTypeIdValue) {
    console.log($(this).attr(“ID”)+” content type id “+contentTypeIdValue);
    $(this).find(“Field”).each(function () {
    var xitem = $(this),
    ListItem = xitem.attr(‘Name’);
    // console.log(xitem);
    // console.log(ListItem);
    listItems[j] = “”;
    // console.log(listItems[j]);
    fieldNames[j] = ListItem;
    // console.log(fieldNames[j]);

    var str = listItems.toString();
    str = str.replace(/,/g, “”);

    operation: “GetListItems”,
    async: false,
    listName: listName,
    ID: $().SPServices.SPGetQueryString()[“ID”],
    CAMLViewFields: “” + str + “”,
    completefunc: function (xData, Status) {
    $(xData.responseXML).SPFilterNode(“z:row”).each(function () {
    if($(this).attr(“ows_ID”) === $().SPServices.SPGetQueryString()[“ID”]){
    for (var k = 0; k < listItems.length; k++) {
    var value = $(this).attr("ows_" + fieldNames[k]);
    // console.log("This is "+fieldNames[k]+" value "+value);
    if (value != "undefined") {
    var element = $("[name='" + fieldNames[k] + "']");
    if (element.prop("tagName") == "INPUT") {
    $("input[name='" + fieldNames[k] + "']").val(value);
    else if (element.prop("tagName") == "SELECT") {
    $("select[name='" + fieldNames[k] + "']").val(value);


    as you can see, I added logic based on the z:row ows_ID. If this isn't done, then the form will display the last row in the .each loop displaying incorrect information, yet updating the correct item in the list.

  11. One thing I forgot to add is to change the value of k =0 to k=1. This will correct the loop iterations to the proper iterations per field by removing the contentType ows selector as seen below.

    [prevObject: n.fn.init[1], context: document, selector: “[name=’ContentType’]”, jquery: “2.1.3”, constructor: function…]

  12. Hi,
    I am new to SharePoint online. I observed that office 365 do not really support InfoPath. I want to migrate InfoPath on SharePoint online. As it is not much supportive please suggest me some other way to carry out InfoPath functionality on other forms. And FYI my InfoPath form do contain data connections(.udcx) files. Any sample code related to the same with form related to it will be much helpful.Please suggest some workaround.

    P.S. I am planning on deploying the functionality of InfoPath form as an App to SharePoint online(to my existing online site).

    Thanks & Regards,

Leave a Reply

Your email address will not be published.