Microsoft Office InfoPath 2007 is one of the lesser-known tools in the Microsoft Office suite of applications. Compared with Word and Excel, it has a much smaller user base and an even smaller number of people who actually know what to do with it. In this article I explain what InfoPath can offer, focusing on how to use it with Microsoft Office SharePoint Server (MOSS) 2007. I use a common real-world expense report example to illustrate InfoPath’s benefits. SharePoint’s recent popularity makes InfoPath a useful tool that your organization should investigate and evaluate.
InfoPath Basics
InfoPath is essentially a tool for designing and creating forms. The application allows nontechnical users to build and deliver methods to collect and manage data. Although a common perception is that you can accomplish the same tasks with Word or Excel, InfoPath provides greater functionality. In addition, you can easily convert Word and Excel files to more robust InfoPath data-collection forms.
InfoPath is really just a package of associated files. At its heart is an XML file that represents the data source for your collected data inside the forms. This flexible format is extremely useful for additional applications to read and process the form data. The designer or front-end view is simply XSL, with some additional files to manage rules, data connections, and so forth. If you rename your InfoPath template with the .XSN extension to a .CAB file, you can extract and view the individual components as text files, and you can easily see how they are connected.
InfoPath has built-in capabilities to connect with Microsoft SQL Server, Access, SharePoint, and Web Services to read and write data to a significant number of additional applications and data stores. These features make InfoPath an excellent option for building small applications that connect to multiple systems at once to select and update data. In addition, InfoPath can then collect and send data in human-readable formats via e-mail or to SharePoint. Most of these tasks can be accomplished with no compiled coding.
Two significant features of standard InfoPath development are the rich rules and validation components that users can build without code. The application lets the form designer view and manage common interface controls. The underlying data source can be viewed and manipulated with intuitive XPath functions abstracted away from the designer. For example, you can have a number of rules on a control; these rules check the contents or any other controls, process calculations, or immediately let you know which rules passed or failed. Rules can be strung together to cover some fairly sophisticated data validation and specific display control management.
You can save sections of forms as templates for reuse across multiple forms. This approach eliminates cutting and pasting and gives organizations the option to build components with specific functionality or required schema items to share with form designers.
SharePoint Integration
InfoPath connects natively to SharePoint in multiple ways. It can read data from SharePoint lists quickly and easily, query live SharePoint data, and return results to the form to process a variety of options for the designer or end user. Connection options include binding data to drop-down lists for selection, obtaining user profile information, and querying sources of configuration data for rules, validation, and much more. InfoPath forms can be stored locally in SharePoint document libraries in the same way as any other type of document. They can be made the default template for a given content type, allowing the New command on a list to automatically create an instance of these custom forms to open, fill out, and save locally in the library for business processing.
Forms Services
Some of the real power when using InfoPath with SharePoint lies in the use of InfoPath Forms Services, which is an enterprise feature of SharePoint that dynamically translates an InfoPath form to a web page via specific server technologies. Consider my previous example, in which an InfoPath form is used as the template for a content type. Web-enabling the form lets you build and publish forms directly to SharePoint and use them to start collecting XML data immediately, without requiring any additional client software beyond a web browser.
Forms Services is context-aware from a SharePoint perspective. It knows who is logged on, giving you additional flexibility in managing permissions and security for data access. When querying and using SharePoint data, you get the built-in security trimming to ensure that only appropriate access is given for each form instance.
Significant options are available for designing forms and collecting data. InfoPath is designed to send chosen fields to SharePoint fields as metadata, using out-of-the-box functionality with very little user effort. This data can then be searched with SharePoint’s robust indexing and searching components or used to drive workflow, business logic, or custom applications that already exist within your environment.
InfoPath is a significant upgrade over standard SharePoint data collection with built-in lists. Typically with SharePoint lists, the designer has limited ability to make changes to the out-of-the-box new forms or edit forms that are generated on all SharePoint lists. These standard forms lack certain flexibility, such as the ability to limit access to specific fields when editing a SharePoint list item, or provide dynamic access to controls or additional data sources outside of traditional SharePoint lookup columns. SharePoint’s native storage mechanism of list items limits the potential for exporting and accessing the list data in the robust way an InfoPath XML form can. All of these problems are quick and easy to address if you choose InfoPath as the form to collect data. InfoPath is also extremely easy to set up.