C H A P T E R 11
Using InfoPath Forms
InfoPath forms allow designers to create rich, custom forms that can create and consume data from a variety of sources including SharePoint. In this chapter, you will explore the features of InfoPath forms that make them well-suited to inclusion in a SharePoint-based solution. You will examine the concepts and security considerations to be addressed when working with InfoPath forms in SharePoint. You will then learn the process for building and publishing different types of forms for use within SharePoint.
You will learn about the following topics in this chapter:
- The basics of creating web-enabled forms by using InfoPath 2010
- The limitations placed on web-based forms in terms of security and functionality
- How to control the deployment of form templates in a SharePoint environment
- How to customize SharePoint list forms by using InfoPath form templates
- How to integrate custom document information panels with Microsoft Office applications such as Word or Excel
Introduction to InfoPath
Let's start off our discussion of InfoPath by pointing out that this book is about SharePoint Designer, not InfoPath. Why then is this chapter called “Using InfoPath Forms”? That's a good point…on to Chapter 12!
Just kidding. The reason for discussing InfoPath here is that data entry forms occur naturally in many situations when designing SharePoint sites. InfoPath and SharePoint are designed to work well together, and some interesting features can best be leveraged by using both technologies together. This chapter will not attempt to teach you everything there is to know about designing InfoPath forms. There are many good books on that subject already. The purpose of this chapter is to introduce the concepts of InfoPath and to explore the situations for which a SharePoint site designer may find using InfoPath forms helpful.
The Form-Filling Environment
When Microsoft released InfoPath as part of MS Office 2003, it saw slow adoption because of the way users had to fill out forms. The MS InfoPath 2003 client application was used to both create form templates and fill out forms. In order to get InfoPath, most organizations had to sign up for volume licensing and more-expensive editions of MS Office. Although integration with SharePoint was considered a valuable feature, there was no way to create a web-based data entry form in InfoPath. Because most users did not have InfoPath on their desktops, deploying an InfoPath form in any but the most controlled internal-facing scenario was impractical.
Compare this situation with InfoPath's competitors such as Adobe's Acrobat forms. Acrobat forms can be designed using the full Acrobat client application, but they can be filled out using the Acrobat Reader application, which is available as a free download. The lack of an equivalent form-filling environment caused many organizations to reject InfoPath as a solution.
When InfoPath 2007 was released, it provided the capability to create web-based forms. These form definitions were designed to run within SharePoint's InfoPath Forms Services subsystem. Forms Services was included in the Enterprise license of MOSS 2007 or as a separate product called SharePoint Forms Services 2007. This strategy eliminated much of the restriction on InfoPath's adoption, but web-based forms have certain security limitations that prevent them from being used in all cases.
Tip The fact that a form template is deployed to SharePoint does not require that it be web-based. A non-web-based form opened from SharePoint will open in InfoPath Designer or InfoPath Filler if available. Only if InfoPath is not available will this type of form fail to open.
With the release of InfoPath 2010, Microsoft has adopted a three-pronged strategy for filling out forms. InfoPath forms can now be used in three distinct environments:
- InfoPath Designer 2010: This Windows-based client application is used to design or fill out InfoPath form templates. This is the authoring environment for forms.
- InfoPath Filler 2010: This Windows-based client application is used to fill out forms based on form templates designed in the designer application. This application allows forms to use the same security model as forms running in InfoPath Designer.
- InfoPath Forms Services 2010: This is a subsystem within SharePoint Server 2010 Enterprise Edition that hosts web-based InfoPath forms. This allows a user to complete and submit forms without installing any client application, but with more-restricted functionality.
Note Unfortunately, the new InfoPath Filler application is not the revolution it seems to be. Microsoft did not see fit to release it as a free download like Acrobat's Adobe Reader application. In fact, under the covers, this application runs the same executable as the InfoPath Designer. It just runs in a different mode. As such, users still need to buy an upscale edition of MS Office in order to use it. The same barriers to adoption exist for InfoPath 2010 that were present in the 2007 version.
What's New in InfoPath 2010?
The 2010 release of InfoPath contains new features to make forms easier to design, more functional to use, and more versatile to host and deploy. These new features can be divided into three main categories, as follows:
- Designing form templates
- Page layouts: Allow the designer to apply a variety of standard layouts to a form view.
- New controls: Include picture buttons, date/time pickers, person/group pickers, digital signatures and managed metadata pickers.
- Improved rules engine: New types of rules allow the quick creation of complex behaviors without coding. Also includes an improved rule management interface.
- Quick Publish button: This option allows the designer to republish a previously published form without going through the entire publishing wizard again.
- SharePoint integration
- SharePoint list forms: The new display and edit forms generated for a SharePoint list can be replaced with an InfoPath form template for added control and functionality.
- SharePoint workspace integration: SharePoint lists and libraries taken offline using SharePoint Workspace (previously known as Groove) can still leverage InfoPath forms. Forms entered offline are synchronized with SharePoint when a new connection is made.
- Web-based forms
- More supported controls: Includes lists, list and combo boxes, picture buttons, hyperlinks, pickers, and sections.
- InfoPath Form web part: This web part allows any InfoPath web-enabled form to be hosted on a web page in SharePoint, including connecting the form to other web parts via web part connections.
- Browser standards compliance: The new version is compliant with XHTML 1.0 and Web Content Accessibility Guidelines 2.0 (WCAG 2.0) AA.
InfoPath Integration with SharePoint
InfoPath integrates with SharePoint in several ways, but the underlying technology supporting that integration is the InfoPath Forms Services subsystem. This component is part of the Enterprise edition of SharePoint Server 2010.
Forms Services is configured in SharePoint's Central Administration site. Unlike other SharePoint services, such as Excel Services or PerformancePoint Services, Forms Services is not a service application configured under Application Management. To configure Forms Services, select the General Application Settings link in the left-hand menu and look for the InfoPath Forms Services group.
To enable InfoPath Forms Services features within SharePoint site collections, you have to activate the SharePoint Server Enterprise Site Collection feature. This feature activates the web parts and menu actions necessary to host InfoPath forms within the site collection.
After you have configured and enabled Forms Services in the site collection, you can use the InfoPath form templates in various ways. InfoPath forms are XML-based. This means that all of the data entered is encoded into an XML document that is then submitted to a data store of some kind. The most basic use of InfoPath forms in SharePoint is to use a SharePoint document library as a repository for storing completed forms. SharePoint provides several features that are useful when working with forms, including versioning, access security, and workflow processing.
A form template can be integrated with a library in two ways. The simplest way to surface a form in a library is to publish the form template as a document template in the library. The problem with this method is that the form template is stored specifically for this library and isn't usable elsewhere in the site. A better approach is to associate a form template with its own content type. Adding the form's content type to a library allows forms to be filled out and stored in the library. The advantage is that the content type becomes a centralized location for managing the form template. You will explore creating a form content type in Exercise 11-1 later in this chapter.
The next most common use for InfoPath within SharePoint is for creating customized forms for workflows. SharePoint workflows allow users to perform controlled business processes managed by the Windows Workflow Foundation (WF) engine hosted within SharePoint. The WF engine can assign tasks, send e-mails, or perform a number of other activities in order to complete a business process. At each step in the process, user input may be required. The forms for entering this data are called task forms. InfoPath can be used to create highly customized templates for the forms. You will explore this type of form in Chapter 12 when you examine SharePoint's workflow features.
A new feature in InfoPath and SharePoint Server 2010 is the ability to create custom list forms in InfoPath. When a list or library is created in SharePoint, a set of default data entry forms is created. These forms create new items and edit or display existing items. A site designer can now customize these forms by using InfoPath form templates more easily than using the other methods available. You will customize list forms in Exercise 11-2 later in this chapter.
The final scenario where InfoPath forms are useful to site designers is when using SharePoint in conjunction with other MS Office client applications such as Word or Excel. Office applications allow the document author to set document properties such as the author, title, keywords, and so on. These properties can be viewed in the document information panel (DIP). In Word 2010, this panel can be displayed by selecting File from the Ribbon and then selecting Show Document Panel from the Properties drop-down to the right of the Backstage area. InfoPath and SharePoint can be used to create custom DIPs that will appear in Office applications when a document is opened from within SharePoint. Data entered into these panels can be stored as metadata with the document in SharePoint. You will create a custom DIP later in this chapter.
Understanding Security Considerations
Security is a complex topic when working with InfoPath forms because a form will often touch many resources outside the form. InfoPath forms can contain data sources that retrieve data from databases, web services, or other locations. Each of these interfaces may require its own authentication and authorization mechanism in order to function properly. Form templates may also contain managed .NET code that can access files on the user's system or perform other potentially dangerous actions.
To control the use of these features, InfoPath has form security levels. Each security level places a different set of restrictions on what actions the form template can perform. The form-filling environment also affects what actions a form can take. Forms running in InfoPath Designer or Filler have greater freedom than those running in a web browser. A comprehensive discussion of the rules governing the restrictions placed on forms at different security levels is beyond the scope of this book, but a general description of these levels follows.
Restricted Level
Forms running in Restricted mode cannot communicate with resources outside the form template's definition. This is the most secure, but least functional, mode in which a form can run. There are many InfoPath features that will not function in a Restricted mode form. The following is a partial list of the features that can't be used in this mode and a brief description of why they are not allowed:
- ActiveX controls: These controls run in a nonmanaged execution environment, where their actions cannot be limited.
- Roles: Role definitions require information about the user that is not part of the form's template.
- Data connections: Data connections access information that is external to the template. An exception to this rule is when submitting a form via e-mail. Submitting a form via e-mail is allowed because e-mail forms are the primary use of restricted forms.
- Workflow forms: Data must pass in and out of workflow forms, which violates the restriction.
- .NET managed code: Managed code will not load in a Restricted form because the .NET runtime is not available. The form will still load, but none of the .NET code will execute. No error will be displayed. This allows a template to use .NET code when running in InfoPath Filler while still functioning without code in a web-based form.
Because any form template that is deployed to SharePoint is, by definition, communicating with SharePoint, Restricted mode forms cannot run in SharePoint. Restricted mode forms are generally used for e-mail forms, where security limitations are extremely tight.
Domain Level
The Domain security level is the most commonly used mode for InfoPath forms in SharePoint. This level is an intermediate step between Restricted forms and those requiring Full Trust (which you'll learn about next). Domain mode forms can access external data as long as that data is accessible according to the domain's security zone as defined by Windows Internet Explorer.
Note It is important to recognize that InfoPath's use of the word domain is not the same as a domain in Active Directory or in Internet web addresses. For example, the Internet addresses www.microsoft.com and office.microsoft.com may or may not represent different security domains depending on the configuration of zones in IE on the user's system.
When a form is opened from a SharePoint list or library, it is running as a URL-based form. The URL used to open the template is checked against the security zones defined on the user's desktop to determine whether it is in the Internet or Local Intranet zone. In Domain mode, external resources are restricted based on their zone relative to the zone of the form template.
InfoPath's security model also defines a URN-based form that maps to the Local Computer zone. However, SharePoint-based forms are always URL-based, so we don't cover URN-based forms in this book.
Full Trust
The most permissive level of security for an InfoPath template is Full Trust. In Full Trust mode, a form can access any resources that the person filling out the form can access. This may include databases, files on the local hard drive, and Registry settings. Obviously, Full Trust forms should be used only when absolutely necessary because of their potential for unintended impacts to the user's system.
The good news is that forms cannot get Full Trust just by asking for it. In fact, it can be quite difficult to get a form template installed in a way that allows Full Trust. In order to run a form in SharePoint using Full Trust, the form must be digitally signed using a trusted root certificate and it must be installed by a farm administrator through SharePoint's Central Administration site. The form can't be directly published by the designer.
Note that Full Trust does not eliminate any of the limitations on a web-based form. A web-based form running in Full Trust must still refrain from using features that are not supported in such forms. Making a form require Full Trust simply opens up new communication options.
Configuring Security Levels
A form's security level is configured in the InfoPath Designer application when it is designed. By default, InfoPath determines the correct security level for the form based on the features used in it. When the designer adds a data source, for example, the form will automatically be promoted out of Restricted mode.
To set a specific security level for a form, select the File tab in the Ribbon to open the Backstage area. Select Form Options and go to the Security and Trust area in the Form Properties dialog box. This panel allows the designer to set the security level and, if desired, sign the form template.
Creating Form Templates
InfoPath forms run the gamut, from very simple forms that collect a few fields, to highly complex data entry applications with multiple views, data connections, and complex business rules. This section presents the things to consider when creating forms for use in SharePoint.
Planning
The first step is, of course, to plan the form you are going to create. Taking a few extra minutes up front to organize the presentation and functionality of a form can make a big difference to the end user.
Security and Filling Environments
When designing a form, you have to consider the security level that the form will need to run at and the environment the user will be expected to use when filling out the form. For security levels, Table 11-1 lists some rules of thumb.
Remember to consider the desktop environment of the user who will be filling out the form and the features required by the form. If the user does not have InfoPath Filler on their desktop, your form must be web-enabled and forgo using any features not supported in web-based forms.
Data Connections
As with any data entry application, when designing InfoPath forms, you must consider where data is coming from and where it is being stored. In InfoPath, these become the data sources or connections.
The form's primary data source is the XML document that represents the data entered into the form. The data for this form generally gets written to a data store when the form is saved or submitted. In the case of SharePoint forms, the primary data connection is usually to a document in a document library or a list item.
Secondary data connections may retrieve data from databases, web services, or other SharePoint locations. The important thing is to ensure that whatever security credentials are needed to access that data are available in the intended filling environment. For example, a SQL Server connection string for a database connection can contain a password only if InfoPath Forms Services has been configured to allow it. A best practice for data connections is to use a data connection library to house a set of shared connections. These connections provide a level of trust that makes it easier to move and reconfigure form templates in SharePoint.
Using form templates in SharePoint also introduces two new data considerations: promoted values and web part parameters. When a form is published to a form library, it can expose some of the values from the form to the SharePoint environment. This allows users in the SharePoint environment to search and sort on data within the form without the need to open each form in the library. Using the new InfoPath Form web part on a web part page allows the form to interact with other web parts on the page through web part properties. When publishing a template, form values can be exposed as input, output, or input/output parameters from the web part the form is hosted in. This allows other web parts to feed data into an InfoPath web form and to receive values from it.
Roles
InfoPath roles are similar to audiences in SharePoint Server. Using a set of rules, the user filling out the form is assigned to a set of roles. Depending on which roles the user has, the form can be customized to show a different view or set of functionality.
Roles are not intended as a security feature because the user still has the ability to view the raw XML document after it is stored. Hiding information on the form template won't protect it after it is written to a form library or a disk file.
Another limitation of roles is that they work only in InfoPath Designer or Filler. Web-based forms cannot use roles. This limits their usefulness in SharePoint sites where web-enabled forms are preferred.
Views
InfoPath form templates can contain multiple pages, called views. Every template starts out with one default view. Additional views can be added that present the form's data in different ways. Each view can have its own layout and style. A view does not need to display all of the form's data. Like roles, views should not be used as a security feature. Some common reasons for using multiple views in forms include the following:
- To simplify a large form by splitting it up into more-manageable pages
- To create a print-friendly view of the report
- To show different data to different users based on their role or the current state of a business process
Adding Behavior
In this context, behavior refers to any action taken by the form that isn't a direct response to a user action. This includes field validations and calculations that occur within the form beyond the controls' normal abilities to accept input. InfoPath contains multiple mechanisms for implementing custom behavior in forms.
The simplest way to implement behavior in a form is to use rules. Rules are a declarative way to indicate what the form should do in response to certain events. Rules are either validation, formatting, or action rules. A rule may have a condition that must be met and a set of actions to take in response to the event. For example, a rule could be triggered when the Budget field is greater than $100,000. The resulting action could be to set the Approver field to CFO. InfoPath also contains a formula language that can be used to define calculations directly in some situations instead of using rules.
There are some types of logic that need to be written in a full-featured programming language. InfoPath supports writing managed code, using VB.NET or C#, that runs in the .NET runtime. Forms that run .NET code must run in either the Domain or Full Trust security level. Because .NET code has the ability to do a great deal of damage and consume a lot of server resources, InfoPath has been designed to control its use by using SharePoint's “sandbox” approach.
Caution Previous versions of InfoPath supported writing business logic in scripting languages such as JScript and VBScript. This functionality is now deprecated in favor of managed .NET code.
SharePoint Server 2010 contains a new system for hosting untrusted code in a safe, reliable way. Code running “inside the sandbox” is executed in a separate process from the rest of SharePoint. This prevents it from interfering with the server's basic functions and allows the farm administrator to limit the amount of server resources such code can consume. Sandboxed code can access only a subset of the .NET Framework that has been designed to prevent untrusted code from causing problems. This subset excludes connecting to databases, accessing files, or calling unmanaged code. For a more complete discussion, see the TechNet article at http://technet.microsoft.com/en-us/library/ee704541.aspx.
Web-enabled InfoPath forms always have to be able to run in the sandbox. They run in Domain security mode and can access only SharePoint resources that are within the site collection where they are deployed. Any .NET code they contain must adhere to the limitations of a sandboxed application. .NET code in InfoPath can access the InfoPath object model through a set of API calls. There are two versions of the DLLs containing these calls. One is a subset of the other and contains only those features that are valid for use in a sandboxed form. The references to these DLLs are set correctly depending on the compatibility settings for the form. A form that is set to be web-compatible will automatically bind to the more limited object model and .NET Framework classes.
Tip There is a subtle but important difference between a form running sandboxed .NET code and one running no code at all. A form running without code runs within the security context of the user accessing the web site. A form running sandboxed code runs in a separate sandbox service process. As a result, such a form will be unable to access the identity of the user after the form is open. The InfoPath username() function is designed to resolve this problem. It will return the correct username even when the form is running in the sandbox.
A form that cannot live within the restrictions of a sandboxed form can still be used within SharePoint. In that case, the form must be set to Full Trust and be published by a farm administrator. Also, because web forms must be sandboxed, Full Trust forms must be filled out by using InfoPath Filler, not a web browser. As a result, the fully trusted code runs on the user's desktop, not on the SharePoint server.
Publishing Templates
After the form template is complete, it needs to be published. A published form is more than just a copy of the form in a particular location. Think of publishing a form as compiling a computer program. After the template is published, it is ready to be used for filling out forms.
There are various ways to publish InfoPath forms, including publishing to network file shares, local directories, and as installable executable files (MSI). However, these do not apply to SharePoint and therefore are not discussed here. The options for publishing form templates to SharePoint include publishing to form libraries, content types, and farm deployments.
When a form is published directly to a SharePoint document library (called a form library when using forms), the template becomes the document template for the library. When the user creates a new document in the form library, the form is launched for the user. The form template is stored in the site directory housing the library. The template is used only by that library and is maintained separately from any other form templates in the SharePoint environment.
Instead of publishing directly to a form library, the template can be deployed as a content type in SharePoint. In addition to the form template, the site content type can define data fields, workflows, and information management policies such as retention rules. A content type can be used multiple times throughout the site collection. This simplifies maintenance for a widely used template because there is only one central copy to be updated when a change is made.
A form template can also be published at the farm level by a farm administrator. This places the template in a centralized, trusted, farmwide repository. Deploying form templates at the farm level allows them to access certain capabilities that are not available to templates at the site collection level. A farm-level template can be used by a library or content type housed in any site collection in the farm. Only a farm-level template can run in Full Trust mode, allowing it to access any data source and execute unrestricted .NET code.
Building InfoPath Forms for SharePoint
Now you will do some hands-on work, using InfoPath forms to augment the design of your SharePoint site. You will create a web-enabled form, customize the data entry forms for a list, and create a document information panel for a new project management office within your organization.
Before proceeding through these exercises, be sure to do the following:
- Ensure that InfoPath Forms Services is up and running in your SharePoint environment.
- Create a new site to work in. Any site template will work. This example uses a blank team site in a new site collection.
- Be sure that the SharePoint Server Enterprise Site Collection Features option is activated in your site collection.
- Install the InfoPath Designer 2010 client application on your workstation.
Tip For more information on configuring InfoPath Forms Services, see the TechNet article at http://technet.microsoft.com/en-us/library/cc262263.aspx.
EXERCISE 11-1. CREATE AN INFOPATH FORM FOR USE IN A FORM LIBRARY
In this exercise, you will create a simple form for entering data. When the user submits the form, it will be placed into a SharePoint library, where an approval workflow will be started automatically. First, you will create a form template in InfoPath Designer. You will publish the form to a new content type in SharePoint. You will enable the standard approval workflow for the content type and create a library to host your forms.
- Open InfoPath Designer.
- From the Backstage New area, select the SharePoint Form Library template.
- Click the Design Form button to the right, as shown in Figure 11-1.
Figure 11-1. Selecting a form template
The default form template provided contains a title area and two table layouts. You can add or remove any of these elements as desired. First, you will define the data you want to capture:
- In the Fields pane, shown in Figure 11-2, right-click myFields and select Add.
- In the Add Field or Group dialog box, enter ProjectName for the field name and select the Cannot Be Blank check box. Leave the field type as Text. Then click OK.
- Repeat step 5 to create a ProjectManager field.
- Create a BudgetEstimate field with a type of Decimal (Double).
- Create a StartDate field with a type of Date (Date).
- Create an EndDate field with a type of Date (Date).
These fields define the XML document that will be used to store the form's data. Now you will remove one of the table layouts and populate the form with controls:
- Click in the top panel that currently reads Click to Add Title and type Project Initiation.
- Click the table handle for the lower table, as shown in Figure 11-3. This selects the entire table.
- Press the Delete key. This removes the second table layout from the form.
- Select the second, third, and fourth cells in the first row of the remaining layout table.
- From the Ribbon's Layout tab, select Merge Cells from the Merge group.
- Merge the same cells in the second row.
- Drag the ProjectName field from the Fields pane to the first row of the table. Put the label in the first cell and the text control in the second.
Tip InfoPath will try to help put the label and control in the correct place. When dragging the field, watch how the cells are highlighted before you drop the field. If you drop the field while both cells are highlighted, InfoPath will put the label in the first cell and the text control in the second. InfoPath even adds a space between Project and Name for you.
- Drop the ProjectManager field in the second row in the same way.
- Drop the BudgetEstimate field in the first two cells of the third row.
- Click in the lower-right cell in the table and press Tab. This is an easy way to add a new row to the table.
- Drop the StartDate field on the first two cells of the fourth row.
- Drop the DueDate field on the last two cells of the fourth row.
Figure 11-4. Completed form template in InfoPath Designer
- Select the File tab from the Ribbon to activate the Backstage area.
- Click the Publish button.
- Click the SharePoint Server button.
Before publishing the form for the first time, InfoPath requires you to save the unpublished form. This version will be used to update the form template in the future. You will save it to the desktop for simplicity:
- In the Save As dialog box, click the Desktop link.
- Type ProjectInitiation as the filename.
- Click the Save button. The Publishing Wizard is displayed, as shown in Figure 11-5.
- Enter the site collection URL where the content type will be stored and then click Next.
- On the wizard's next page, shown in Figure 11-6, leave the check box labeled Enable This Form to Be Filled Out by Using a Browser selected.
Note If this option is missing, the probable causes are (1) InfoPath Forms Services is not configured correctly or (2) the SharePoint Enterprise site collection feature is not activated in the site collection where you are trying to publish the form.
- Select the Site Content Type (Advanced) radio button and then click Next.
- On the wizard's next page, shown in Figure 11-7, select the Create a New Content Type radio button.
- In the Base This Content Type On list, select Form and then click Next.
- On the wizard's next page, shown in Figure 11-8, enter the name and description for the form and then click Next.
Figure 11-8. Publishing Wizardnaming the content type
The form used by a content type must be published to a location in the site. You can create a new document library or use an existing one. In this case, you will use the FormServerTemplate library that already exists in the site:
- On the wizard's next page, shown in Figure 11-9, click the Browse button.
- Double-click the document library to store the template in the list displayed.
- Enter ProjectInitiation for the template filename and then click Save. Back in the wizard, click Next.
Figure 11-9. Publishing Wizard—setting the template location
The next step of the wizard is used to designate which fields in the XML form will be made visible to the content type as fields. You also have the option of exposing fields as parameters for connecting web parts. You will want to promote those fields that are useful for searching and sorting.
- Click the Add button near the top of the dialog box.
- Select the ProjectName field from the list, as shown in Figure 11-10, and then click OK.
- Add the ProjectManager and StartDate to the list of promoted fields as well, as shown in Figure 11-11. Then click Next.
Figure 11-11. Publishing Wizard—adding promoted fields
- Click Publish to complete the process.
- When the process is complete, click Close to exit the wizard.
- Close InfoPath Designer.
At this point, you have created a content type based on your new form template. You still have to configure the approval workflow and create a form library to store the completed forms:
- Open the site in SharePoint Designer 2010.
- From the Navigation pane, select the Content Types Gallery.
- Under the Microsoft InfoPath group, click Project Initiation Form to open the content type's settings page.
- From the Ribbon's Manage group, select Administration Web Page. Note that the three columns you promoted from the form are visible as columns in the content type, as shown in Figure 11-12.
Figure 11-12. Form content type settings page
- Click the Workflow Settings link.
- On the Workflow Settings page, shown in Figure 11-13, select Add a Workflow.
- Select the Approval—SharePoint 2010 workflow.
- Enter Project Approval for the workflow name.
- Under Start Options, select the check box labeled Start This Workflow When a New Item Is Created.
Figure 11-13. Workflow settings page
- Accept all other defaults and then click Next.
- The next form, shown in Figure 11-14, is for configuring the workflow. Enter a set of approvers and any other parameters as appropriate. Then click Save.
Figure 11-14. Approval workflow configuration
The setup of the content type is now complete. Finally, you will create a new form library to host the content type:
- In SharePoint Designer 2010, select Form Library from the Document Library drop-down list in the New group on the menu.
- Enter Project Forms for the name and then click OK.
- In the List and Libraries Gallery, click the Project Forms link.
- On the settings page, select the check boxes labeled Allow Management of Content Types and Require Content Approval for Submitted Items.
- Save the changes to the list (Ctrl+S).
- In the Content Types pane, click Add.
- In the Content Types Picker, under Microsoft InfoPath, select Project Initiation Form, as shown in Figure 11-15. Then click OK.
Figure 11-15. Content Types Picker
- In the Content Types list, select Form.
- On the menu, deselect Show on New Menu in the Actions group. Only the Project Initiation form will be configured to show on the new menu.
Your form is now ready to be used. The form library you have created has inherited the promoted fields, form template, and approval workflow directly from the content type you created.
- Open the list in a web browser (F12).
- Click the Add Document link.
- Enter data into the Project Initiation form displayed, as shown in Figure 11-16. Then click Save.
- Enter a name for the file. Click Save.
- From the menu, click Close.
The form you entered has been added to the form library, and the approval workflow has been started. The same content type can be used in multiple form libraries, and multiple form types can be hosted within this library. The value of using form content types is seen when it is necessary to update the form template. By updating the template associated with the content type, that update is automatically seen by all libraries that use the content type.
EXERCISE 11-2. CUSTOMIZE LIST FORMS BY USING INFOPATH
Tracking issues during a project is a common task performed by using lists in SharePoint. You will start with the standard issue list template available in SharePoint. Then you will create a custom InfoPath form for entering, updating, and viewing issues to suit your specific needs.
- Open the site in SharePoint Designer 2010.
- From the Navigation pane, select Lists and Libraries.
- From the SharePoint List drop-down menu in the New group, select Issue Tracking, as shown in Figure 11-17.
Figure 11-17. Creating the Issue Tracking list
- Name the new list Issues and click OK.
- Click the Issues list to go to the settings page.
- Press F12 to view the list in the web browser.
- Click the Add New Item link. This displays the default New Item dialog box for the list, as shown in Figure 11-18.
- In SharePoint Designer, on the Ribbon, select the List tab under List Tools.
- Click the Customize Form button in the Customize List group of the menu, as shown in Figure 11-19.
Figure 11-19. Customize Form menu item
Tip If the Customize Form button is missing, it is probably because you forgot to activate the SharePoint Enterprise features in the site collection.A new form template, shown in Figure 11-20, launches in InfoPath Designer 2010. This form is a replica of the default form generated by SharePoint. The fields in the pane to the right represent the columns in the list. These are the data elements for the form. Now you will remove and rearrange the fields in your form.
Figure 11-20. Default InfoPath list form
- Right-click the Attachments row and select Delete
Rows. - Right-click the Related Issues row and select Delete Rows.
- Right-click the Category row and select Cut.
- Click in the leftmost part of the cell containing Issue Status.
- Right-click and select Paste Options: (Keep Source Formatting), as shown in Figure 11-21.
Figure 11-21. Pasting fields without losing formatting
Now that you are finished changing the appearance and behavior of the data entry form, you must publish it back into SharePoint.
Figure 11-22. Finished list form template
- From the Ribbon, click the File tab and select Quick Publish.
Note There is no need to tell InfoPath where or how to publish the form template because it was created specifically for your issues list. Quick Publish simply publishes it back to that location and installs it for you.
- In a few moments, a dialog box appears, indicating that your form template was published successfully. Click OK.
- Close InfoPath Designer.
- Back in the web browser, you are still on the All Items view on the Issues list (see Figure 11-23). Click the Add New Item link again. The New Item form is now rendered by using your form template.
Figure 11-23. Customized list form in the browser
- Enter some data and then click Save to submit it to the list.
- The item now appears in the Issues list. Clicking the title opens your new form in Display mode.
- In SharePoint Designer, open or refresh the settings page for the Issues list.
Three new forms have been added to the Forms pane: displayifs.aspx, editifs.aspx, and newifs.aspx, as you can see in Figure 11-24. If you open these pages in the Page Editor, you will see that they use the BrowserFormWebPart control to display the form template in the necessary mode (New, Edit, or Display). This control is the InfoPath Form web part, which uses Forms Services to display the form.
Figure 11-24. Customized forms in thelList
To make further modifications to this form template, simply go to the list view in the browser and click Customize Form again. This reopens InfoPath Designer and reloads the form template. If you ever need to access the InfoPath template file (XSN) directly, you can select All Files in SharePoint Designer and look in the content type's subdirectory under the list. In this case, the path within the site is /Lists/Issues/Issue/template.xsn.
Figure 11-25. All Files—customized template file
EXERCISE 11-3. CREATE A DOCUMENT INFORMATION PANEL
In our final InfoPath exercise, you will create a document library for storing project documents such as requirements, designs, and project schedules. The documents in this library will have additional metadata fields defined in a content type. You will create a DIP for this content type that will integrate these metadata fields into whatever MS Office application is used to edit these documents.
- Open the site in SharePoint Designer.
- In the Navigation pane, click Site Columns.
- From the menu, click the New Column drop-down and select Single Line of Text.
- Enter Project Name for the column name, as shown in Figure 11-26. Then click OK.
Figure 11-26. Creating a site column
- From the menu, click the New Column drop-down and select Choice.
- Enter Document Type for the column name and then click OK.
- Double-click the Document Type site column in the gallery list.
- In the Column Editor dialog box, enter Requirements, Designs, Schedules, and Other for the choices, as shown in Figure 11-27.
- Set the Default Value option to Other. Then click OK.
- Click the Save button in the window title bar or press Ctrl+S. This saves the new site columns to SharePoint.
Now that you have created the site columns that will store your custom properties, you will create a content type to represent the document itself:
- In the Navigation pane, click Content Types.
- Select Content Type from the New group in the menu.
- Enter Project Document in the name field.
- From the Select Parent Content Type From drop-down list, select Document Content Types.
- From the Select Parent Content Type drop-down list, select Document.
- Under Existing Group, select Document Content Types. Click OK.
- In the Content Types Gallery, click the Project Document link.
- On the settings page, click the Edit Content Type Columns link under Customization.
- On the menu, select Add Existing Site Column from the New group.
- Select Project Name and then click OK.
- On the menu, select Add Existing Site Column from the New group.
- Select Document Type and then click OK.
- Click the Save button in the window title bar or press Ctrl+S. This saves the new content type to SharePoint.
Figure 11-29. Content Type Editor
The content type you have just created will be used to store project documents in a document library. To implement the DIP, you must attach an InfoPath form template to the document content type.
- Click Project Document in the breadcrumb control to return to the settings page for the new content type.
- Select Administration Web Page from the Manage group in the menu.
- In the web browser, click the Document Information Panel Settings link.
- Click the Create a New Custom Template link.
Figure 11-30. Document Information Panel Settings page
- InfoPath Designer opens to an informational dialog box. Click Finish.
- InfoPath displays a default DIP form based on the fields in the content type, as you can see in Figure 11-31.
Figure 11-31. Default DIP form template
Note The Title field is included, but the Name field is not. The filename cannot be changed from a DIP form because this type of form is used when the file is open. - Make some changes to the layout of the form.
- Click the File tab of the menu and select Quick Publish from the Backstage area.
Note As you saw for a custom list form, there is no need to tell InfoPath where or how to publish the form template. In this case, however, SharePoint Designer will insist that you save your unpublished DIP form template outside SharePoint before it publishes it to SharePoint. Future changes to the DIP template should be made in the saved file. The template is then republished to SharePoint.
- In the Save As dialog box, save the unpublished form template to your hard drive.
- In a few moments, a dialog box appears, indicating that your form template was published successfully. Click OK.
- Close InfoPath Designer.
- In the web browser, use the link provided to return to the DIP settings page (see Figure 11-32). Note the location of the DIP template stored in SharePoint.
- At the bottom of the page, select the check box labeled Always Show Document Information Panel. Click OK.
Figure 11-33. DIP Settings page
Note A DIP form template must be published to the same security domain as the document that will use it in order to function correctly. In our example, the template is being published to a document library within your site collection. This is a good practice to prevent security issues when dealing with these panels. If the form template is stored elsewhere, be certain that users can access it without crossing domains.At this point, you have only created a content type for your documents and the document information panel you want to use. You still have to create a library and associate your content type with it:
- In SharePoint Designer, select Lists and Libraries from the Navigation pane.
- Select Document Library from the Document Library drop-down in the New group in the menu.
- Name the new library Project Documents. Click OK.
- In the Lists Gallery, click the Project Documents link to open the library's settings page.
- In the Settings panel, select the check box labeled Allow Management of Content Types.
- Save the changes by pressing Ctrl+S.
- In the Content Types panel, click the Add button.
- Select Project Document from the picker and then click OK.
- Select the Project Document type in the Content Types list. Click the Set as Default button in the Actions group on the menu.
- Select the Document type in the Content Types list. Click the Show on New Menu button in the Actions group on the menu.
Figure 11-34. Project Documents library settings
The document library has been configured to contain either a document or a project document. You can't remove Document as a content type, but you have removed it from the New menu so users won't see that option anymore (see Figure 11-35).
- Press F12 to open the list in the web browser.
- On the menu, select the Documents tab under Library Tools.
- Select the Project Document option under the New Document drop-down.
Figure 11-35. Creating a new project document
- Type some content into the new Word document and save it to SharePoint. After the file is saved, the document information panel appears, as shown in Figure 11-36.
- Enter data in the DIP form and save the document and save it again.
In the library list, select View Properties from the document's drop-down menu. Note that the properties you entered are now part of the document's metadata. You can add as many properties as needed by using DIPs. You can also add other behaviors to the form by using InfoPath's other features such as roles, views, and rules.
Summary
In this chapter, you have
- Explored the concepts of InfoPath 2010 forms
- Examined the security and functionality considerations associated with browser-enabled forms in InfoPath
- Learned how to create and deploy InfoPath forms to a SharePoint environment
- Customized the new, display, and edit forms for a SharePoint list by using InfoPath
- Created a document information panel and deployed it in SharePoint to collect custom document metadata
