Recently I’ve been involved in the development of a SharePoint 2007 solution using InfoPath and Forms Services. The purpose of the solution was collection of employee questionnaire data using one of several forms designed as a multi-page survey. InfoPath was chosen because the process needed to make use of SharePoint workflows, which are not supported with survey responses. Also, the survey form needed to behave differently depending upon whether an employee or their manager was completing it.
I wanted to use this post to document some of the things I learnt during the development process.
Only Use Custom Code if Rules and Views Can’t Do the Job: You can do an awful lot with InfoPath Rules and Views to give the user a good experience when completing a form. You also have the added advantage that when publishing your browser-compatible form to SharePoint Forms Services, you don’t have to deploy it as an Administrator-approved form. Over at EnduserSharePoint, Paul Galvin has posted a useful starter template for InfoPath which includes views for handling successful submission and discarding the form. And there are other useful InfoPath tips on Paul’s blog.
“Wizard” Style Forms Work Well Using Views: Using [Next>] and [<Back] buttons combined with views, you can create a nice “wizard” style user interface for your form. Here’s a nice post from the MS InfoPath team on this topic.
But You can Only Validate a Maximum of 5 Fields Using a Rule: This is one of the issues which required use of custom code. On our “wizard” style form, there are 7 questions per page, and the user should not be able to move to the next page until all 7 have been answered. So we ended up putting validation code on the “click” event of each “[Next>]” button. This tutorial from DevExpertise explains how it’s done. It ended up as one of the reasons for a custom code requirement – I guess it might also be possible to to this using XPath, but as we also ended up needing code for another feature (see below), we used custom code here.
If You Want to Pass URL Parameters to your Browser Based Form, You Need to Write Some Code: For this solution, a manager could be assigned multiple questionnaires to complete (one for each person they are managing). So we wanted to pass the ID of the employee into the new form, then this would be used to look up employee details on a secondary data connection. Turns out that you can only read URL (querystring) parameters using code. Here’s a post from the InfoPath Team showing how to pass/retrieve these parameters.
Use Site Columns for Promoted InfoPath Fields: Our solution required two different forms to be available as content types in the same forms library. If both of these forms use the same set of promoted columns, your life will be a lot simpler if you first create the columns you want to promote as a set of site columns specific to the solution. If you don’t, and you deploy the forms to different servers, you can end up with multiple “Microsoft InfoPath” site columns with same name but different IDs. Also, we wanted to promote some InfoPath text to SharePoint multiline text columns. This doesn’t seem to be possible using the default “Create New Column in this library” option but can be done using site columns.
Ensuring your Submitted Forms Have Unique Names: You need to ensure that the submitted form has a unique name. Here are couple of items you might find useful – Hannah Scott: Submit InfoPath forms to SharePoint with Unique File Name and SharePoint User Group UK Submit InfoPath with unique filename using SharePoint Library ID.
Centrally Managed Data Connections Make it Easy to Switch from Dev to Test to Production: Converting your SharePoint data connections to centrally managed ones makes it much simpler to move your solution between servers or web applications. To make this work you will either first need to use a data connection library for data connections, then upload these using Central Admin, or use this UDC File Authoring Tool (which is also an InfoPath template). More information here and here.
If You Are New to InfoPath, Read Paul Culmsee’s “Humble Leave Form” Series”: Paul Culmsee of CleverWorkarounds fame has written an amusing and useful series on InfoPath called A Tribute To The Humble Leave Form. There are 7 parts to the series so far, all based around a leave form for the Springfield Nuclear Plant. In part 5 Paul discusses using the UserProfile web service to get more useful info about the user completing the form.
I hope others embarking on InfoPath/Forms Services projects find some of this useful!