InfoPath 2010 with SharePoint 2010: A Walkthrough

InfoPath is a versatile data-collection tool designed to make the creation of forms within SharePoint extremely easy, efficient, and connected to out-of-the-box or custom workflows. And yet, for IT pros and even SharePoint developers, InfoPath remains a mysterious application. Because SharePoint adoption is steadily increasing, I want to pull back the veil to show you how you can integrate InfoPath forms in your SharePoint environment without the need for coding.

In “Solve Common Business Problems with InfoPath and SharePoint,” I discussed the benefits of combining InfoPath with SharePoint. In this article, I'll dig a little deeper, showing you how to build a form from the ground up, using InfoPath 2010 Beta 2 and SharePoint 2010 Beta 2. As I walk through some examples, I'll also point out ways to enhance certain components or functionality with custom code.

See also, "SharePoint 2010's Value for Admins."

Getting Your Feet Wet

First, you’ll want to use InfoPath 2010 to create your first form. I want to focus mostly on InfoPath, so I won’t spend too much time on the SharePoint infrastructure; however, I’ll cover some of the SharePoint 2010 requirements where necessary. To get started, open InfoPath 2010 and click File, New from the top ribbon. You should see an image similar to Figure 1.

 

 

Select the SharePoint Form Library template, then choose Design this Form in the navigation pane. You’ll see a new form in the design window with a basic-looking table from which to add labels and controls. To start, we’ll create a lightweight expense report form to illustrate how quickly you can begin to gather data into SharePoint.

Within the designer, you can select a color scheme under the Page Design tab. Remove the unwanted rows and add some quick labels to get the form to look bland and ready to have controls added to it, as Figure 2 shows.

 

 

Place your cursor in the table cell to the right of the Date cell, and from within the Home tab select the Controls menu item. Within this menu, select the DatePicker control. You should see a new DatePicker control added to your design surface where your cursor was placed, and a new XML element added to your Fields box on the right, as you see in Figure 3. These fields represent the data you’ll capture and their associated type. If you right-click the DatePicker control and select Properties, you can set formatting rules and supply a more readable name for the underlying data it represents. As you add more controls, you’ll get a growing XML container file ready to capture your form data in a standard format.

 

 

When adding data elements and associated controls, you should strongly consider giving your data the correct type (e.g., numeric, text, date, Boolean) and applying specific formatting and rules for these controls—anything from enforcing currency formatting to complex functions such as using XPath to evaluate other data elements to enable or disable controls based on the value of one or more other controls within your form. Doing so can add significant options.

I’ve filled out the design surface with some additional controls to show you what a basic expense report might look like. InfoPath provides much more extensive options for additional rules, formatting, and connectivity to additional data sources for querying and for creating business logic within your form. In the case of expense reports, you might want to query your SharePoint lists or SQL Server databases to obtain employee department and manager information automatically, mileage rates, per-diem amounts, and so on. This can easily be included to make more dynamic and flexible forms. Figure 4 shows a rudimentary expense report form. (I added a repeating table with some additional data collection to account for a varying number of expense items that can be filled out by end-users.)

 

 

Repeating tables are powerful within InfoPath. They represent something that competing options don’t: easily capturing any number of user-defined records at run time while still maintaining all your rules, formatting, and functions. In other applications, many designers use to collect data (e.g., Microsoft Excel, Word, ASP.NET) creating a “add another item” for the user can be very frustrating within a single form. Excel has difficulty with using functions in named ranges when it doesn’t know how many rows it must account for; ASP.NET forms must create the new row in code and then be specifically built to manage the code to iterate over all the submitted record. InfoPath manages this data very easily because it knows in advance that there might be any number of rows within a group (XML Nodes). Most of the rules and formatting are automatically applied to each new row as it’s created and filled out.

Publish Your Expense Report

If you would like to examine your XML container file, you can use the File menu in InfoPath and choose Publish, Export Source Files. Doing so will export the InfoPath package from an XSN file into native components. If you open these files, you can begin to make some sense of how InfoPath is packaged and designed. Under the covers, it’s basically an XML schema definition, XML template, an XSL stylesheet (used to create your display elements), and an associated XSF file, which is a proprietary InfoPath file used to apply the rules, datasource details, and other native functionality.

If you feel particularly daring, you can make modifications to these files manually and repackage them into your XSN file. If you ever want to venture into building InfoPath forms in Visual Studio to add compiled code, this becomes very easy. Some of the potential benefits include copying and pasting rules for faster and less risky reuse, assigning property promotion to SharePoint via specific Site Columns in advance, and understanding how rules and data sources are applied. Although this is an advanced topic, it’s important to know how the files are put together in case you ever need to crack them open.

With a basic Expense Report form built, we’re now ready to publish and use it inside SharePoint 2010. The first necessary action is to perform a design check to ensure that the form we’ve built can properly function within InfoPath Form Services. These services, native to SharePoint, can convert your InfoPath form into a fully functional web page by simply publishing the form to SharePoint. Select File, Info, Design Checker. In the Design Checker window, click the Change settings link at the bottom. Choose Web Browser Form in the dropdown list, then type in the URL to the SharePoint site where you wish to publish the form. Then, click OK. Select the Verify on server check box, and click Refresh. A dialog box will inform you that the form is being checked against your server.

The Design Checker will be your friend as you design larger and more complicated forms, up until your form gets too big—at which point, it will abruptly cease to be your friend. It will time out when trying to convert and evaluate your form to make sure it can be properly converted to a web page. This was a major problem in InfoPath 2007, and I’m hopeful that a fix is in sight. Even if the checker times out, your form will still work in SharePoint. The best option is to disable the Design Checker when it begins to time out. As long as your forms aren’t very large, you’ll be told if you’re attempting to use any InfoPath features that aren’t supported with web forms.

The next step is to select File, Submit Options, and insert the path to your document library where you want to store the filled-out forms in SharePoint. In the File Name text box, you need to set something that will enforce unique values to ensure that you don’t have duplicate file names. There are many ways to do this, but for now I just used the date of the report with some text: concat("Expense Report - ", ReportDate). Select Next, and choose a name for this data connection. This represents one way to quickly submit data to SharePoint, but you might find that you need to add submit buttons with more flexibility. For example, a button can run some rules and analysis on the data before allowing a submission.

The next step is to select File, Publish, Publish form to a SharePoint Library. Insert the URL to your SharePoint list and select Next. On the next page, ensure that you select the Enable this form to be filled out by using a browser check box. Choose the Site Content Type radio button, and select Next. By selecting this radio button, you’re telling InfoPath that you want this form to be added as the template for a new SharePoint Content Type. On the following screen, select Create a new content type and select Next. Now, add a name and description for your new content type and select Next.

On the following page, you need to decide where to place this template so that it can be used by the new Expense Report content type. I usually like to put the template in a place where it can’t be easily accessed. In this example, you can hide it in the list’s Forms folder so that it will reside in your new form library but will be tough to readily find. (Here’s where I placed mine: http://2k8-sp2010-dev/Expense Reports/Forms/ExpenseReport.xsn.)

The following screen is where you’ll promote local fields in your InfoPath form to SharePoint lists as columns. Click the Add button on the upper list. In the Select a Field or Group dialog box, select any fields in your form that you want to promote to SharePoint. In the Site column group dropdown list, select (None: Create a new site column). Below that, create a name for your new SharePoint column. This screen will enable SharePoint to automatically extract data from your submitted forms to your SharePoint site columns with no additional effort. You will see this in action when you submit your first form shortly. Continue to add as many columns as you want. Figure 5 shows my test form.

 

 

For a more robust and reusable solution, you’ll want to create your required site columns in advance within SharePoint. In that case, you can tell InfoPath to use them instead of creating new ones when publishing your form from within InfoPath. This becomes a powerful tool for collecting essential managed metadata from external sources and using custom search options in SharePoint to create a legitimate application around expense reporting or any other business process you might need to automate.

Now, you can continue through the remaining dialog boxes and publish your form. And you can browse to SharePoint to test your form. When you navigate to your form library, you must first disable the default form content type and add your new Expense Report Form content type. To do so, navigate to Library Tools, Library, Settings, Library Settings from within your Form Library. Click Advanced Settings, and ensure that the Allow management of content types? checkbox is selected. Then, navigate back to your Form Library Settings, and in the Content Types section, select Add from existing site content types, locate your new content type in the list box, and add it to your library. Return to the previous page and in the Content Types section, click Change new button order and default content type and clear the Form box so that it doesn’t appear in the list of available content types for this library when adding items.

When you’re done with that, you can see your form in action by returning to the library and selecting Library Tools, Documents, New Document, Expense Report Form from the available document types. You should see your form in your browser window, as you see in Figure 6. (I’ve filled out some data to show what it can look like.) At the top of your screen, you should be able to submit the form and return to your SharePoint list.

 

Workflow

Now that you have a working expense report form, I’ll walk you through the process of creating a workflow to allow submissions of expense reports to be approved by the accounting department. You’ll use SharePoint Designer 2010 Beta 2 for this task.

Related: SharePoint Workflows

Open SharePoint Designer and choose to open your site via the URL. After seeing your site information page, select Workflows in the left navigation. You’ll see a list of workflows that already exist in your site. SharePoint 2010 now supports modifying the out-of-the-box workflows using SharePoint Designer 2010. In this case, you’ll create a brand-new workflow for your expense reports. To see some new features in SharePoint Designer 2010, select Reusable Workflow from the ribbon menu. SharePoint Designer 2010 can now create workflows that can be saved as templates and reused, or in this case attached to your expense report content type. Figure 7 shows the Create Reusable Workflow dialog box.

 

 

Select OK after you fill out the form. SharePoint Designer will connect to your server and create the shell for your new workflow. In the ribbon, select Insert, Action, Start Approval Process. You’ll see your new action appear in Step 1. Click Step 1 and rename it, for example, Expense Approval—something to help denote the intention of the step. Now, click the underlined these users. In the Participants field, you can put the user or group that will be assigned the approval task. In the Title field, you can click the ellipses to build a string with some dynamic values. In this example, I allowed for a duration of two days for the task. When you’re done, click OK.

Now, you can save and click Publish in the ribbon. Navigate back to your SharePoint site and to your Expense Report list. In the ribbon, click Library Tools, Library, Library Settings, Expense Report Form (content type), Workflow Settings, Add a Workflow. Select Expense Report Form for the Content Type, then select Expense Report Approval Workflow for your workflow template, and give your workflow a unique name. The rest of the settings can probably stay as defaults. I ran into what I believe to be a beta problem that required me to click the Back button after selecting my content type (in order to select my custom workflow). Remember that some of these names might be different, depending on how you name your workflow and what content type is selected. When you’re finished, click OK. Your workflow is now ready to run. To test the workflow, create a new expense report and select Workflows in the item’s context menu.

On the Start a New Workflow page, you can select your custom workflow and click Start. Doing so should create an approval task for your accounting user. This user will have the option to approve, reject, reassign, and so on. Assuming he or she approves your report, you’ll see an Approved link in the custom workflow column in your expense report library. If you click on the link, you should see a screen similar to Figure 8.

 

 

This screen contains a lot of information, including any tasks created during this workflow, plus all the history data logged by the workflow process. There are some errors logged in my history because I didn’t get email correctly configured in my test environment. You’ll also notice another new feature at the top of the image: Visio Services. SharePoint Designer 2010 workflows can be exported and imported via Visio to provide a more robust and familiar design surface for workflow creation. These services automatically created a flowchart to depict my custom workflow. You’ll see the benefits of this feature as your workflows become more complex with additional steps and business logic.

This is an example of the most basic workflow. I don’t have enough space to go into more depth, but if you look through the available actions for workflow steps, you’ll get an idea of what’s available. You can also custom-build these actions in Visual Studio and use them in SharePoint Designer. Workflows can make decisions based on user input, look up data from the current item or SharePoint lists, and span multiple users. They are capable of significant complexity.

Related: Workflow Solution

Extremely Powerful

Although this is a quick and relatively simple display of the technology, you can see how easy it is to build custom forms with workflow, and you can get a sense of the additional power and flexibility at your fingertips. Combining workflow, some custom code behind the forms, robust rules, datasource connectivity, and the ability to package and deploy forms for re-use across multiple locations, InfoPath is an extremely powerful tool in conjunction with SharePoint. I should also point out that all the form-development functionality is similar to that of InfoPath 2007 and Microsoft Office SharePoint Server 2007. Although some of the screen layouts are different, everything we walked through can also be built in the current version of these products. Only the workflow components at the end have changed significantly in the 2010 release.