InfoPath Development Best Practice and Catches

Posted in: SharePoint 2007, SharePoint 2010, SharePoint 2013 | Feb 11, 2013 at 10:23 AM

No comments

INTRODUCTION

I have been developing InfoPath with SharePoint for years and in this article I would like to share some tips that I’ve learnt throughout these years which I believe have helped me and I know will help you, too.

InfoPath is such a great product. And when we are talking about electronic forms, InfoPath is definitely my product of choice. Not only can it build forms pretty rapidly, it also has many built-in functionalities such as connecting to external data sources, assigning field validations and many others. The only complication that I often experience though is deployment to SharePoint.

So first of all I would like to discuss about the type of InfoPath development that you can do with SharePoint.

USING MANAGE FORM TEMPLATES IN CENTRAL ADMIN

The first approach is by deploying your form as a managed form template in Central Admin. If you open Central Admin then go to General Application Settings -> Manage form templates, you can upload your XSN (ie. InfoPath Form Template) in there. You can then activate the XSN to a particular site collection. What this will do is creating a custom site content type in your site collection which you can then attach to a document/form library.

The site content type is automatically associated with your XSN. Therefore, if you try to create a new document using the content type, InfoPath will automatically trigger use your form template.

The benefits:
– You can use ALL InfoPath features including repeating tables, etc.
– The generate Site Content Type can be attached to any document library within the site collection.

The disadvantages:
– Upgrading the form template can be time consuming as you have to re-upload the updated XSN through Central Admin.
– If you need to make InfoPath fields available in your list, you have to manually promote them.
– There is no direct linking between your form template and the list column meaning that if you create a list column, you can’t directly reference it in your template.
– If you remove a promoted field from the template, you WILL get an error if you try to open submitted forms that were submitted using the old template (so be careful!).
– Migration to another site collection with different URL can be challenging as you need to extract the XSN, modify the manifest.xsf and update the URL then re-publish the form template.

The best practice:
– For all data connections ensure you convert them to UDCX in the site collection then Approve them otherwise you may get an error when the form tries to access these connections.
– Form template has to be signed with a certificate before you can publish it in Central Admin. When you sign a certificate do NOT use the InfoPath tool but rather go to Start ->  All Programs -> Microsoft Office -> Microsoft Office 2010 Tools -> Digital Certificate for VBA Projects. This tool will generate a 6-year expiry certificate while the InfoPath only generates 1-month expiry.
– When assigning a certificate select DOMAIN instead of FULL TRUST. With FULL TRUST user will be prompted for an invalid certificate if the certificate is self-generated, while the DOMAIN will not.
– Hide the SUBMIT button on top-left-hand-corner and rather use a custom BIG SUBMIT button at the bottom of the form.
– If you create a custom SUBMIT button make sure you call Submit action first before Close This Form. The Submit action will trigger field validations.

USING CUSTOMIZE FORM BUTTON IN CUSTOM LIST

Another way of developing InfoPath form with SharePoint is through the CUSTOMIZE FORM button. The button only appears on Custom List. Try it…create a list using Custom List template then on the ribbon, click on List and you will notice a Customize Form button. If you click it, InfoPath will open and you can then modify the VIEW ITEM, EDIT ITEM and ADD ITEM page of that list using InfoPath.

The benefits:
– You have direct access to the list columns.
– All data connections are relative to the site collection, so you don’t have to worry about publishing your data connections into UDCX files.
– Migration is very simple. Simply save the list as a template then restore it.
– Form is auto-trusted so you don’t have to assign a certificate.

The disadvantages:
– Limited feature. Features such as repeating tables are not available.
– Form template is attached only to that particular list and the list of available fields are dictated by the list columns.

The best practice:
– Do not convert any of the data connections into UDCX or you will have problem with migration.
– Do not turn on SUBMIT feature as the form template will be opened within the VIEW ITEM, EDIT ITEM and ADD ITEM context (which means the SAVE button located on the ribbon is what’s used).

WHICH OPTIONS TO USE?

It all depends on the needs. I personally prefer the first approach (ie. the full-blown managed form template approach) but it is obviously a bit more complicated than the second approach.

GENERAL BEST PRACTICE

– Form needs to be idiot-proof. Meaning, user should never get any error message or they will be very reluctant in using it.
– PRINT button needs to be made available in Form Services page (FormServer.aspx) because users will be looking for it. By default no PRINT button is available but instead Print Preview. I’ve written a script on this blog post to display a custom Print button.
– If you ever do a username comparison from either People Picker or User Profile Service (/_layouts/_vti_bin/userprofileservice.asmx), make sure that you UPPERCASE or LOWERCASE the usernames prior to comparing! Why? Because the usernames returned by People Picker, User Profile Service and username() method may be in different alphabet casing, and when this is the case, the comparison will fail. For example, sometimes People Picker may return TFSCONSULTING\tommy.segoro but the User Profile Service may return tfsconsulting\Tommy.Segoro and when you are comparing these two (either using EQUALS or CONTAINS), even though the usernames are exactly the same, if they are on different casing, the condition will return false.
– If you ever need to build a custom approval workflow, do NOT use the Task List auto-email notification. Turn that off and rather create a Custom Code task in your Visual Studio workflow to send a custom email. Why? The OOTB Task List notification email contains a direct link to the submitted form except it will automatically open the InfoPath client if user has InfoPath client on their machine (even though you have set in the library settings to open in the browser). And not just that, the OOTB Task List will send a notification email every time the task status is changed. The problem is, when the task is either approved or rejected, the email you’ll get will always say, “Task is completed” instead of “approved” or “rejected” respectively. So from the user point-of-view it is very confusing.

No Comments Yet.