Smarter ideas worth writing about.

InfoPath Best Practices

 

If you are not familiar with InfoPath it is a form tool available from Microsoft, part of the Office Professional Suite. One of the main purposes of the tool is to allow a business user to quickly create a form that can be used organization wide to collect data without the need for a developer.  This is not always the best approach but it does help get something up and running quickly. I have used InfoPath forms quite a bit over the years to convert paper processes into electronic processes by easily incorporating the forms into a SharePoint environment.  More importantly, I have used them in multiple Fortune 100 companies where no custom code was allowed in SharePoint environments.  It is important to note that while InfoPath can be a great solution is not always the best approach to solving a problem. Be sure to do careful analysis of the application you want to create. If the requirements are overly complex you should consider a custom solution.

In this post, I will discuss some of the common practices that I have used over the years. These are practices that I find helpful in organizing my forms so that I can always understand them, but more importantly, other developers or business users can get up to speed quickly when enhancements are requested.  Most of these practices pertain to naming items appropriately. It always makes the job a little easier when I walk into a client to make some enhancements and find the form controls organized in a coherent fashion. The opposite of this typically leads to hours of figuring out what component of the form does what, or what logic is associated to which control. Sometimes I have found it easier to build a form from scratch rather than hunt down the one item I need to change. So let’s get started.

 

Plan

Do not simply open a blank form template and start adding controls. Reorganizing all of the fields can be cumbersome. Think about how the form is going to work. Are you going to want certain sections to hide based on status or user? Do you want a specific layout? Do you need to following branding guidelines? Do you need to publish to SharePoint? Will a SharePoint workflow be running against this form? Do you need signatures? These are just a few of the questions you may need to ask yourself or your business partner prior to building the form. I would recommend documenting your plan, create a rough sketch, list all of the fields and field types. You may find it helpful to work with a Business Analyst to structure the requirements to help you along the way.

 

Naming Conventions

Name fields/sections/groups something that will make sense to everyone. The odds are you will not be the only person to customize the form.

It is a good practice to use camel or pascal case for your field names. If you are not familiar with the terminology camel case is when you capitalize all words after the first word without spacing such as camelCase. Pascal case is when you capitalize all words without spacing such as PascalCase. Naming your fields using these methods will automatically add spaces if the fields are published to SharePoint.

This is optional, but you should consider adding alternate text to controls. Every control within InfoPath has the option to add this property. This will help the end user understand what the control is used for. It also helps to make the form easier to read by accessibility tools such as screen readers. For example you may have two radial buttons for a yes/no scenario, for each radial you could put a description in the alternate text like “Select this if you agree”, or “Select this if you disagree”.

 

Grouping Columns

I recommend creating a section/group for the main areas of your form. If you add a section to the page it will automatically create a group in the data source. It will also add the fields into the group when added to the section. Sections can also be hidden based on status or even groups and users. For example an onboarding form could require fields that need to be completed by a hiring manager and fields to be filled out by IT. You could hide the fields that need to be filled out by IT from the hiring manager based on the SharePoint groups those users are in.

 

Repeating Tables

Repeating tables are essentially groups with multiple tiers. Again pay attention to naming these tiers appropriately. I typically name the first tier (folder) with the table’s purpose followed by table, for example BestPracticesTable. The second tier (folder) keeps the table’s purpose but is followed by row, for example BestPracticesRow.

 

Rules

Name these as well. InfoPath defaults these to Rule 1. Nothing will drive you more crazy opening up the logic inspector and seeing 100 Rule 1’s and each rule does something different. For example if it’s a rule that hides field a based on field b the rule should be named Hide field a when  field b equals x.

 

Buttons

Name the controls to indicate the actions they perform. Sometimes requirements are complex enough where multiple Resubmit, or Submit buttons are required.  Each one may have different actions it performs. When these are not named it makes it difficult to determine which button does what.

 

Data Connections

If you know the data connection the form will be using, perform a check to ensure that the connection to your resource does not already exist. If it is a common resource I recommend using a data source library to store the connection file. This allows the data connection to be available to more than one form. The data connection libraries are approval based so this allows more control and is commonly used to meet governance requirements.

 

Browser Enabled Forms

When first creating the form, ensure you have selected that it will be a browser enabled form. This will limit the controls available for use. The design checker will also alert you to any compatibility issues. You may also run into some limitations with the size of formulas and the amount of fields you can publish to SharePoint. These vary depending on the complexities and sizes of the fields. Only publish the fields you need in SharePoint, the most I have ever published to SharePoint was 75, but typically I do not have more than 25.

Make sure you choose the right approach for deployment as well. There are three ways to do this. I do not recommend publishing directly to a forms library.

The three ways to publish a form are as follows:

  1. Directly to a Form Library
  2. As a Content Type
  3. Via a SharePoint Administrator to Centrally Manage the form. This type of deployment is required if the form has had additional code added to it.

Be sure to check out the InfoPath Developer Center for additional information.

Oh, and one more thing: if you have access to InfoPath 2010 I recommend you use it - there are numerous improvements in 2010 over 2007. If you do have 2010, but are building for a 2007 SharePoint environment, be sure to start with the 2007 blank template.

Share:

About The Author

Principal SharePoint Consultant
Cory is a principal consultant in Cardinal's Charlotte office. He has been working with Sharepoint since 2005 in a variety of clients and industries.