Microsoft InfoPath 2010 helps organizations streamline business processes and design sophisticated electronic forms....
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
Although InfoPath can be a pretty handy feature, it’s often underused. Even when enterprises do take advantage of its functions, InfoPath isn’t always used as well as it could be.
It’s easy to slap a form together quickly, but a little extra knowledge can go a long way to turn InfoPath into a valuable business tool. Some great benefits of InfoPath include reduced maintenance costs and frustration, content end users, more flexible forms and more comprehensive enterprise solutions.
Some InfoPath best practices include devising a naming convention and sticking to it, building a standard template and creating self-documenting forms. Take them one-by-one until you’ve incorporated them into the blood stream of your daily development cycle and then build upon them over time.
Best Practice #1: Naming and grouping conventions
As with so many SharePoint functions, it’s really easy to create your first InfoPath form. Fire up InfoPath, drag a few controls on the page and publish, and you’ve created your first form. In my opinion, this is an anti-practice, and you should avoid it. Instead, take care to explicitly name both your fields and your groups as shown in Figure 1:
It’s a simple concept, but it has significant implications, including:
- Clarity of business purpose. The meaning of PoNumber is immediately obvious, while the meaning of field23 is not.
- Parsing Forms. Completed InfoPath forms are XML documents. If you think you can live with field23 because it’s labeled in the form, you won’t get that support when and if you need to parse the XML programmatically.
- Promoting fields to SharePoint. No one wants to promote a field called field23 to SharePoint. You do get the option of naming the field from a SharePoint perspective, but now you need to remember that SharePoint field PoNumber is really field23 in InfoPath. That’s a recipe for long-term maintenance frustration. Avoid it at all costs.
Define a naming convention that, at a minimum, ensures that fields are named according to business purpose. Some developers like to prefix fields with their data type, follow camel or reverse-camel notation -- the specific field naming convention doesn’t matter that much as long as it’s consistent across forms.
Next, follow a convention for naming views on forms. InfoPath typically lists views in its various functions in alphabetical order. On a multi-page form, this can become confusing because InfoPath doesn’t list the individual pages -- implemented as InfoPath views -- in the correct logical sequence. Solve this problem by prefixing views with numbers and letters to force your own sort order. Consider Figure 2:
Figure 2 shows the following naming convention:
- Numeric prefix to view names representing pages of a form.
- Early letter alphabet prefix for confirmation views.
- P for a print view
- Z for technical views that would not normally be provided to end users.
As with field names, the specific convention is not especially important as long as it’s effective for you and your team and applied consistently.
Best Practice #2: Build a standard template
There are some basic elements to every InfoPath form. Recognizing this fact, build a template that includes the following:
- Default sections in your form’s main data source. The general idea is that we know that our forms will have certain standard groupings of data, such as administrative content, page-one content and possibly others.
- A print view place holder. How many times have you released a form to production and then gotten an urgent request to provide a clean print view of the form? It’s easy to forget adding a print view during development. Avoid this surprise by building a place holder right into the template.
- Developer notes section. We’ll cover this in more detail next.
- Administrative Control View. Forms generally contain state information. Provide a view that allows maintenance developers to quickly view the state information of a given form for debugging and troubleshooting purposes. Secure access to this view by leveraging out-of-the-box SharePoint security.
Best Practice #3: Self-documenting forms
We often think of forms as a data entry vehicle and nothing else. But, they can be self-documenting in at least the following areas:
- Business process state. The next section, The Form as a Database describes how to use the form to manage business process information. Forms can and should provide an organized and intuitive view into that state information.
- Version numbers. Forms change over time. Consider this scenario:
- On Monday, we can release version 1.0 of a form.
- On Tuesday, 100 people fill out those forms and kick off a bunch of associated and long-running business processes.
- Wednesday, we make a critical update to the form and post to production.
- On Thursday, another 100 forms are filled out and business processes start running.
- On Friday, someone calls the helpdesk with a problem.
Now the question is, which form template are we talking about? Is it the Monday form or the Wednesday form? Solve this problem by adding a version number to the template itself, as shown in Figure 3:
This way, when someone calls and asks for help with a form, you can ask them which version number they are talking about.
- Technical notes. Use the form template to store developer notes, specifications, change history -- really, any relevant technical information. Hide these notes behind a secured view and you have an integrated and self-documented solution that will reduce maintenance costs and frustration over time. See Figure 4 for an example:
Best Practice #4: The form as database
Any form worth its salt is really the starting point for some kind of business workflow process. Your typical workflow will cause email messages to be sent off for approval and possibly send messages to external systems -- such as ERP or HR -- handle multi-level approval trees with delegation and so on. For these processes to work properly, they need to keep track of business process state. Who approved it? Who is next in line for approval? Did the HR update process succeed or fail?
The form itself can maintain this state information. Add a section to the form’s main data source for this purpose. Your end users won’t normally see these fields, but your back-end automated process can see them and update them as needed. Then, provide a nicely formatted view to show this data, and you have a single consolidated view of everything going on with this form.
The point here is that a form isn’t merely a vehicle for data entry -- it’s also a database for business processes.
Best Practice #5: Use SharePoint security
Take advantage of SharePoint’s security model within your forms. There are a number of scenarios where you might like to show or hide information on the form based on a current user’s group membership -- SharePoint group, AD group or even custom groups via forms based authentication. At first glance, this seems difficult because there isn’t any convenient out-of-the-box feature that allows us to do this.
We can achieve this indirectly, however, by following these simple steps:
- Create a custom list. The standard OOB custom list is sufficient.
- Create rows in the list and give them a title that maps to a business purpose. For instance, if you want to secure the Admin view of a form, create an item whose title is Admin View.
- Break security inheritance on the row. Ensure that only administrative users have read access to that row. SharePoint will allow you to specify AD users and groups, SharePoint groups and even FBA users/groups.
- Add the list as a data source to the InfoPath form.
At runtime, your form attempts to read the specific row from the list whose title is Admin View. If the user filling out the form has read access to the row, the query will return a non-blank result, and you know the user is an administrator.
Otherwise, they will return a blank result (length = 0) and you know he or she is not an administrator. With this fact established, you can now dynamically hide or disable the Admin view button. Use this technique to secure or dynamically alter the form any time you need to do so based on security group membership.
Using SharePoint can be easy. That’s its weakness as well as its strength. Make the most of the SharePoint platform by instituting some best practices that will make users happy and senior management even happier.
ABOUT THE AUTHOR
Paul Galvin is a SharePoint MVP and co-founder of Arcovis, a SharePoint consulting organization providing services to clients in the New York metro area. Galvin has worked in the IT industry for more than 15 years in areas such as software development, consulting and SharePoint solutions design, where he works with clients to create business solutions using the SharePoint platform. He contributes to the SharePoint community through MSDN forums and his blog at http://paulgalvin.spaces.live.com.