Recently I had to decide between InfoPath Form Library and InfoPath List Form. We first ventured down the Form Library path, but due to certain issues, we ended up re-doing the solution using List Form. This post summarises the issues we encountered.
Please note that this is all in the context of browser-enabled forms with no code behind.
First of all, the MS InfoPath team has written an article that compares Form Library and List Form. You definitely should check out this article.
With Form Library, your submitted data is saved as an XML document in a SharePoint library. You will need to build custom logic in the form to generate a unique file name for each XML document (i.e. the submitted form instance). The degree of complexity of this task depends on how you want the file name to be generated. For example, if it is to be based on the current user ID and the current time, then it is quite straightforward. However, if it is to be based on a sequential number, e.g. Request-1.xsn, Request-2.xsn, etc., then it would be more complicated – as your form may need to query an external source (e.g. the SharePoint library) to determine the next number to use.
With List Form, your submitted data is saved as a SharePoint list item. The unique list item ID is automatically generated by SharePoint and your form does not need to worry about it.
Below is the screenshot of viewing a submitted form in a Form Library:
And now is the screenshot of viewing a submitted item in a list with InfoPath List Form:
The list and the library are in the same site, and the site uses OOTB branding.
Note that the left nav and the top link bar are removed from the Form Library (and the global nav is removed from both). The stripped back look of the Form Library may appear to users as if they have left the site. I have done some research and could not find any sensible way to make the Form Library retains some of the site’s branding elements.
This is one of the reasons that made us abandon the Form Library approach.
Form Library allows read-only users to edit the form. Only when the user attempts to save the changes, does the Form Library reports an access denied error. This is quite a poor user experience. This is illustrated in the screenshots below.
Below I have logged in as a read-only user and selects a submitted form in the library. Note how Edit does not appear as an option on the callout menu (this is good).
Below I have clicked the item link to open the form. This form actually opens in edit mode and I, as the read-only user, can make changes to all fields. I edited the text in the Justification field.
Below is the error message I received when attempting to save the changes.
With List Form, the user experience is much better.
Below I have logged in as a read-only user and click to view a submitted item. The form opens in read-only mode. The Edit button is disabled on the ribbon just as you’d expect.
Clicking the new document link above will actually open the upload page and allow the user to browse for documents on his/her local machine. This may be confusing for users.
The corresponding link in a list with InfoPath List Form opens the New Item Form as you’d expect.
Person columns appear as normal text in list views with Form Library. This means you can’t click on the person name to view their profile in MySite, can’t get the user information summary callout when hovering over the name, and can’t get the user’s presence information.
The screenshot below is from a Form Library.
Now this one is from a list with InfoPath List Form.
Note that there are workarounds for this, e.g. having a workflow on the library that runs on document updates, and set the value of a separate User field, and include this User field on the list instead of the one on the InfoPath form. This of course adds complexity to the solution.
Form Library InfoPath forms can be deployed via feature activation from a custom solution, or by manually uploading the form to Central Admin, then activating the right feature from the target site collection. To deploy an updated form during development you will need to either redeploy the solution, or re-upload the form to Central Admin. It seems that either of these cause the app pool of the target site collection to recycle, and therefore add a few seconds to each dev-debug cycle (depending on how fast your dev machine is). In the long run this adds up and reduces your productivity.
With InfoPath List Form, during development you would publish the form to the target list using InfoPath Designer. This is very quick and does not cause the app pool to recycle.
Our project also involved Nintex Workflow 2013. The promoted fields cannot be referenced in Nintex’s Update Item activity. This means you cannot use Nintex Workflow to update these fields.
This is because the submitted form is stored as an XML document, and the promoted fields contain an XPATH expression to the appropriate elements in the XML document. This is why reading values from these promoted fields is OK, but updating them is a problem.
Note that this is not restricted only to Nintex. The same limitation exists for other code. For example, in a console app, I was able to read the values from the promoted fields but could not set them. I imagine that to set them, you will need to update the actual XML document. Consider this carefully, as even though it may not be an issue right now for your current requirements, it may be in the future.
With InfoPath List Form, because the submitted item is stored as a normal SharePoint list item, you do not have this limitation.
OK enough bad things about Form Library :).
With Form Library, InfoPath Designer allows you to convert the main data connection to a connection file. This file then can be uploaded to a Connection Library on the target site collection, or to Central Admin. This connection file defines the target library that the form instances will be submitted to. This means it is easier to promote the form through difference environments, as you just need to update the connection file to match the target environment.
With InfoPath List Form, the form is tied to the target list. InfoPath Designer does not allow you to convert the main data connection to a connection file. It also does not allow you to re-point the form to another list. This makes it difficult to migrate the form across environments. The only way I have found to re-point the form to another list is to manually edit the manifest of the InfoPath form. This works – and must be supported since it is posted on the official MS InfoPath team’s blog: http://blogs.msdn.com/b/infopath/archive/2004/05/04/126147.aspx :).
This is linked to the last point. You can deploy a Form Library form and its data connection file(s) and perform all the required hooks-up using features, and therefore do not require InfoPath Designer.
With InfoPath List Form, you will need to manually publish the form to the target list using InfoPath Designer (after modifying its manifest to suit the target environment). This increases the complexity of your deployment as it adds a manual step and InfoPath Designer as an additional prerequisite.
This is one of the biggest advantages of Form Library. Because the submitted data is stored as an XML document with Form Library, the data structure is decoupled from the library’s columns. This means you can define any data structure to facilitate your form’s logic without impacting the columns of the library.
With InfoPath List Form, the data structure must map 1-to-1 to the list’s columns. Let say for example you have an Approver field on the form. You want a hyperlink on the form that will take users to the user profile of the specified approver. In InfoPath, you’d need a data field for this hyperlink control. With InfoPath List Form, this will require you to define a corresponding column in the list for this data field. This is not ideal, as this means introducing unnecessary columns to your list (and therefore content type) structure to facilitate your UI requirements.
This is the biggest indicator for when you should pick Form Library over List Form. If you require a complex data structure, e.g. repeating tables, then Form Library is the better choice.
Form Library has separate Save and Submit (and Save As as well) actions. The main advantage with this from my point of view is the ability to enable users to save a form with validation errors and resume with it at a later point in time before submitting. This is often a real business requirement, particularly for large forms.
This is not possible with InfoPath List Form without some messy and tedious validation logic.
Form Library has a Print Preview button on the ribbon when a form instance is opened. This renders a slightly cleaner view of the form ready for printing.
There is no such button with InfoPath List Form.
So in conclusion there seems to be more advantages with InfoPath List Form. For forms with a complex data structure however, you may have to use Form Library.
