My articles, “Publish an InfoPath Form to Multiple SharePoint Sites” and its no-code companion, “A No-Code Solution to Host an InfoPath Form in Multiple SharePoint Sites”, have generated a lot more traffic than just about any other post I’ve made (excepting my post about a minor tweak for IE8).
Looking at the search traffic on my WordPress dashboard, I can get a picture of the kinds of things people are searching for and the information they are lacking when they click to my articles. This post is a response to your queries, and hopefully will answer some of your questions.
I’m going to start with some really basic information, and we’ll move quickly up to more complicated ideas. If you have some idea about InfoPath already, stick with me, because I think you will get some meaty info pretty quickly.
First of all, InfoPath. InfoPath relates to paper-based forms the same way Outlook or other e-mail program relates to a handwritten letter (what we sometimes refer to as “snail mail”). Submission to a data store is immediate, and data can be copied and forwarded and searched easily (assuming you have the right permissions).
Second, templates. An InfoPath form relies on a form template which is stored separately from the form data. The template says how the data will be displayed, and defines the structure of the data in the data file. In order to fill out a form, you need to have access to the form template, and you need to have InfoPath installed (or, as you will see in a moment, access to SharePoint Enterprise with a web browser). You can send the form template file to a user and have them fill out the form, or store the template in a location that people who are to fill out the application can access.
Third, the form data file. As I said, the form data is stored separately from the form template. The form data file is an XML file, and contains the name and location of the form template, so it always knows where to go to get its formatting instructions when it is opened. It contains the data for one instance of the form being filled out. In the paper world, its equivalent is the filled-out form you turn in (or was turned in to you, depending on your role). Just like you would store the turned-in paper form in a filing cabinet somewhere, presumably along with other copies of the form filled out by other people (or by the same person at intervals or at different stages), the data file you would store somewhere for later retrieval.
Fourth, SharePoint. SharePoint is a web application that does LOTS of things. One of the things it can do is store files in a way that is accessible in a web browser. Another thing it can do is store data in a tabular format, similar to a spreadsheet, again accessible from a web browser. And finally (from the perspective of this discussion), SharePoint Forms Services can present InfoPath forms as a web page, again accessible with a browser (if and only if you have the Enterprise edition of SharePoint Server).
Using SharePoint, you can provide a central location from which everyone in your organization can access the same form template by publishing it to a form library, assuming that everyone in your organization has access to SharePoint and has access rights to that library. This allows you to manage the form in a single location, rather than sending an updated template to individual users and hoping they use that instead of the outdated template.
So that is the basics.
It was that access to the template issue that I was addressing in my two posts about publishing a file to two (or more) locations. YOU CAN ALWAYS PUBLISH AN INFOPATH FORM TO AS MANY LOCATIONS AS YOU WANT. The only problem is that each published location is technically a separate form. When you open the form template from library X, the datafile will always look to library X for the template (unless you use one of the methods I describe in the two referenced posts). If you open a form identical to X, except that it was published to library Y, it will always look to library Y for its template. The Y template will never recognize (unaltered) files created with the X template and vice-versa.
Beyond having a location for storing the template for access so users can fill out the form, another consideration is storing the file from which the template was published. The template cannot be edited directly from within the SharePoint server, you have to edit the file and republish the changed file (generally to the same location as it was published before). For collaboration, backup and other reasons, it is a good idea to upload the .xsn files of the forms you publish to SharePoint in a separate document library. You would download the file to your local system for editing, publish the form to the form library, and then re-upload the modified .xsn file to the document library.
For the data file generated by filling out the form, there are several options. By default, a user can save the file to any location (that they have rights to), including their own local system. But of course, until the data is sent somehwere for processing, the data it contains would be pretty useless, as far as I can tell. So, unless the form is expected to take several attempts to complete (and maybe not even then), you will probably want to regulate where the form data is saved. This is where the Submit button comes in.
By default, there is a submit button available in the menu bar of the InfoPath user interface, and at the top and bottom of the web forms generated by Forms Services. Several of my clients have expressed to me the opinion that the web form default submit buttons are not obvious to the end users who will be filling out the forms because the buttons are too small and not located in the place we have been trained to expect to find them by our interactions with the dozens or hundreds of web applications we interact with on a regular basis. The good news is you can add your own custom submit buttons to the form.
Submit buttons do nothing unless you provide actions for them to take. In my next post I’ll provide specifics about making these configurations, but for now I will speak in generalities. You can configure the submit button to save the form data file to the form library that was created when you published the form. But you can also use data connections within the form to submit data to other locations, including other SharePoint lists, databases, and more!
I’ll give you an example. A recent requirement was for a form to record information about events that the client’s representatives would be attending to promote their company. Some of the information to be captured included the location of the event, hotel information, the employees who would be attending, and the equipment and supplies they would need to have shipped to the event. The same form would be used afterward to record information from the event, including contacts made at the event. But that contact information needed to be used in a CRM as well, so the contact data needed to be saved in a location other than where the form data was stored. The solution was to create a separate “Submit” button that sent that particular data to the other location once the data was entered.
You can even save the data file in a location other than where the form template is, or save it to both locations (though synchronizing the copies is an exercise left to the reader, or maybe another blog post). Again, though, you are saving the form data XML file which contains the instructions for where to locate the form template. No matter where you save it, unless you edit the processing instructions, the form data file will look for the template it was created with.
This post covers the first few of minutes of my recent presentation at the November 2010 meeting of the Central Texas SharePoint User Group, “InfoPath and SharePoint: Business Partners”.