Using InfoPath e-mail forms

RATE THIS

infopath1
22 Feb 2006 3:45 PM

9
First Id like to mention that, as part of a recent announcement, the product name for InfoPath 12 is
Microsoft Office InfoPath 2007. This is the name Ill be using from now on in my blog. In my first post I talk
about the benefits of browser-enabled forms. Id like to focus now on the InfoPath rich client and give you
a sense of how it can streamline your daily work with InfoPath e-mail forms. If you are familiar with
InfoPath SP1 you probably know that it already allows you to send forms as attachments in email. So why
is e-mail forms a new feature in Office InfoPath 2007? Well, the limitation in InfoPath SP1 is that forms
are just regular attachments and they are not integrated in your Outlook email environment. So in Office
2007 weve decided to make forms a first class item in Outlook. That means forms can now be viewed,
edited, saved, and forwarded similar to email messages, meetings, or tasks. In addition, e-mail forms can
leverage Outlook PIM features like categories and follow up to add a new dimension to your forms
workflow. E-mail forms now have their own folder type and they even have their own icon . This tighter
integration makes it really easy to work with forms and to leverage all the structured information they
provide without having to leave your familiar Outlook environment. Lets walk thru a short scenario using
InfoPath e-mail forms.
Lets assume I need to collect information about the computers used by my team. First I need to design a
form template to collects this information. For our scenario, InfoPath ships out-of-the-box an Asset
Tracking template, which I will use for this example. In order to be sent out safely in email, forms like
Asset Tracking need to work only with data from within the form and can contain only declarative logic, no
code. Because of these security restrictions we call such forms restricted forms. Once the template is
completed, I need to deploy it using the Publishing Wizard and selecting the option to a list of e-mail
recipients. I then need to specify the recipients, add an optional comment, and send out the form. The
screenshot below shows the e-mail deployment of my Asset Tracking form:

When a member of my team receives the form, she clicks Reply, which opens the form in InfoPath. She
then fills out the computer information and sends the completed form back to me, as shown in the
screenshot below. She has the choice to send me an editable XML form, which is the default, or to send
back just a read-only view. She can also add a comment related to the form in the Introduction field. This
comment is in fact metadata that travels with the forms. The same field can be used, for example, to ask
her assistant to fill out the asset information for her and, for more complex forms, to give instructions on
how to complete the form. Here is an example of a completed asset tracking form (In this case Ive
completed it as a team member and Im sending it back to myself):

Note that at design time I could include a submit button in the form. This will let my team members
double-click on the form, edit it in InfoPath and then click Submit to send it back to me in e-mail, same
as if they replied. However, Submit will validate the form and will enforce the return e-mail address. This
helps if I need to implement a more formal workflow process using e-mail forms.
Now Im switching back to being the data collector. Im expecting to receive a fairly large number of e-mail
forms from my team and I want to be ready to process them. To this end, Im setting up a new Outlook
folder to collect the asset data. I right click on Mailbox and select New Folder. In the New Folder dialog
I need to select the option InfoPath Form Items, which is new in Outlook 2007, and associates the folder
with InfoPath forms. Here is the dialog that creates the assets folder for e-mail forms:

Once Ive created the folder, I can also create a rule that automatically routes incoming asset forms to this
folder. This rule should refer to InfoPath forms, as shown in the Rules Wizard dialog below. Then I need to
pick-up the specific form type out of the list of all the templates that have been cached on my local
machine. For each incoming message, the rule will check if it is an e-mail form of type asset tracking
and will route all the matching e-mails to the assets folder.

Note that forms can be stored in any Outlook folder. However dedicated forms folders will create by
default a new e-mail form based on the template associated with the folder. In addition those folders will
allow property promotion, as explained below.
When each form is saved into the assets folder, the properties that have been market for data promotion
in the template are copied as Outlook properties. The forms in this folder can now be sorted and filtered
based on their promoted properties, You may know how useful it is to take advantage of promoted
properties in SharePoint form libraries. You can see at a glance the work progress captured in weekly
status reports or the results of a team survey. The same experience is now also available on your local
machine, using e-mail forms and form folders in Outlook. Like in SharePoint, the data stored in form
folders can be aggregated and exported to Excel for further processing. Below is an example of asset
forms with properties promoted in the assets folder:

As you can see, in addition to using the properties promoted from forms, I can take advantage of
other properties, like Categories and Flags that Outlook provides for all item, regardless of type. In the
example above Ive flagged the machines that need to be replaced, upgraded, or the new ones that have
been purchased in the last quarter.
When I get all the replies from my team, I will go ahead and process the data. As I mentioned before, the
data is not in some collection of text e-mail messages that I need to read in order to extract information for
my report. It is in a collection of structured forms that I can very easily process and extract the data to
report on.
My next step is to export the data to Excel. I select all the forms in the folder and then select the Export
to Excel option from the toolbar. This option automatically generates a spreadsheet with all the data
mapped from the forms into Excel. Note that the export to Excel is not limited to the promoted properties
in my folder but rather to the entire XML of each form in the folder. Once I have all the data in Excel, I
create a simple pivot table with the number of laptop, desktop, and lab machines for each functional team
and then I chart the data using the new graphics engine. Here is the result of my data gathering scenario
using the e-mail form for asset tracking:

When should you use e-mail forms?

Weve seen how Ive used e-mail forms to gather asset information from my team. E-mail forms could
also be used for many similar scenarios, often ad-hoc, in order to collect data quickly from a group of
people, via e-mail. Examples are creating a survey for your department, gathering feedback from
customer visits, or collaborating with your team on a status report. The common elements of these
scenarios are:

The data needs to be structured otherwise youd just use regular e-mail

The data collection is done ad-hoc theres no need to set up a more formal process

You own the final results it is ok for the final results to be collected in your own mailbox

Once you have the replies, you could process them as needed and/or share the data with your team. In
our example, I am the consumer of the collected information. I will export the data to Excel, review it, and
order new hardware as necessary. For status report, the team lead will be assembling the report, then will
publish it, and present it to the team.
A broader scenario is using e-mail to make other forms available to your users. Your forms could be part
of a formal team scenario like tracking weekly status, a department workflow solution, or an enterprise
wide line-of-business application allowing every employee in the company to update benefits or to submit
their performance reviews. In all these scenarios, the forms can be delivered, filled out, and submitted in
Outlook. We will cover integrated scenarios for e-mail forms in a follow-up post.
Finally an important benefit of e-mail forms is offline filling. As you may know, form templates are
automatically downloaded on your machine on first use. Forms can also be installed as part of a client
setup. Once youve used a form once on your machine, you can fill out any similar forms offline. To make
things even simpler, restricted form templates can be included in the same message with the actual email form. A user can download the form in Outlook, open it, fill it out, and submit it back as e-mail form.
An additional benefit here is that you can complete the form offline, submit it, and be done. The form will
be stored in the Outlook Outbox folder and will be sent out automatically next time Outlook connects to
your e-mail server.
I hope Ive been able to give you a sense of the value of InfoPath e-mail forms as first class items in
Outlook and get you interested in trying them out in Office 2007. Ill follow up shortly with other posts on
new InfoPath features. Stay tuned! Id also love to hear your thoughts and feedback.

InfoPath 2007

Designing Form Templates With

The New Features Of InfoPath
Scott Roberts and Hagen Green

This article is based on a prerelease version of the 2007 Microsoft Office system. All information
herein is subject to change.

This article discusses:

Design once for InfoPath and the Web

browser
Template Partsbuilding reusable
components in InfoPath
Hosting the InfoPath form control
The InfoPath managed code object model

This article uses the following

technologies:
InfoPath 2007, Office SharePoint
Server 2007

Contents
InfoPath Forms Services
Design Once
Template Parts
Document Information Panel
Hosting the InfoPath Form Control
Importing and Exporting Forms
Managed Object Model
Visual Studio Integration
InfoPath 2007 is an XML forms designer and editor package in the 2007 Microsoft Office system.
Now in its third iteration (if you include InfoPath 2003 Service Pack 1), InfoPath has matured into
a fully featured and integrated member of the Office family. In this article, we give you a sneak
peek at some of its highlights and new features.
InfoPath 2007 includes a new Design a Form dialog (see Figure 1) that simplifies the process of
designing form templates. You can also build Template Parts (reusable components you can insert
into multiple form templates) as well as browser-enable your form templates and Template Parts.
Browser-enabled forms are designed in InfoPath and can be filled out either in InfoPath or in a
Web browser. Browser-based forms are hosted using InfoPath Forms Services from Microsoft
Office SharePoint Server 2007.

Figure 1 The Design a Form Dialog

You'll find a number of new controls in InfoPath 2007, such as the Combo Box and MultipleSelection List Box, both of which function like their Windows control counterparts. To
accommodate multiple selections, the Multiple-Selection List Box control binds to a repeating
field in the data source and every selection adds another item to the repetition. As with the
Combo Box, users can enter custom values into the Multiple-Selection List Box; this is
configurable on the control during the design. Other new controls include Horizontal Repeating
Table and Horizontal Region.
Integration with various Office applications is much improved. For example, InfoPath brings native
form-filling capabilities directly to Outlook 2007 and e-mail messages. Other Office system
applications such as Word, Excel, and PowerPoint use InfoPath in their Document Information
Panels, which contain a mini-form that lets users fill in metadata properties on the document.
InfoPath 2007 has many other enhancements: better form merging, exporting data, built-in form
template importers for Word and Excel, the addition of Information Rights Management (IRM) to
form templates, improvements for Tablet PC, and Visual Studio 2005 integration. And there's
InfoPath Forms Services, which lets your InfoPath forms reach out to anyone with or without
InfoPath, at any time, on almost any device.

InfoPath Forms Services

InfoPath is great for building forms, but what about deployment? Not all of your customers will
have access to the InfoPath client applicationand they won't have to. InfoPath Forms Services,
which is built on top of SharePoint Server 2007, uses SharePoint document libraries, content
types, permissions, and administration to deliver an integrated forms-management package.
Moreover, Forms Services is designed to extend the reach of your forms. Not only does it support
Microsoft Internet Explorer on Windows, it can also serve forms to Netscape and Firefox for UNIX
and Windows, and even Firefox and Safari for the Macintosh, and it can render content for mobile
devices such as Smartphones and PDAs.
To get a form template into InfoPath Forms Services for filling out in the browser, you design a
form with the "Enable browser-compatible features only" setting checked from the Design a Form
dialog shown in Figure 1. This is not an up-front requirement; the setting can actually be
changed at any time during the design. While you're designing the form, notice that not all

InfoPath features are available and some will be limited in their functionality in the Web browser.
As we'll see, the few limitations that exist allow the same form to be used in InfoPath and Forms
Services without any modifications. We call this "design once," and we'll review the concept in
more detail in the next section.
Let's design the Status Report sample form under the Customize a Sample link in the Design a
Form dialog shown in Figure 1. This form is already browser enabled, so all we need to do is
publish it to a server running InfoPath Forms Services. To do so, click on the Publish Form
Template link in the Design Tasks task pane. This brings up the Publishing Wizard, with various
options for publishing forms. In this case, we're publishing to a SharePoint Server with InfoPath
Forms Services. Subsequent wizard steps ask which server to use for publishing, whether you
want to create a SharePoint document library or content type, and what form data (if any) to
promote as columns in the library or content type. The last page offers a link to the library where
we've published our browser-enabled form template. From there we can fill out our Status Report
form.
Simply clicking the New button in the document library creates a new Status Report form. By
default, the form will open in the InfoPath client application if it's available. That's because
InfoPath is the preferred client for form filling (though there's a setting in the library to default to
the browser). If InfoPath is not available, the form will render in the browser automatically. Figure
2 shows a filled-out form in InfoPath Forms Services. Notice that browser forms support rich text
editing (as seen in the Summary field) with the Rich Text Box control. For comparison, Figure
3 shows the exact same Status Report filled out in the InfoPath client application.

Figure 3 Filling Out the Same Status Report Using InforPath

Figure 2 Filling Out the Status Report Form in a Web Browser

Design Once
Design once means you can create a form template that will work properly within both the
InfoPath application and a Web browser. There's no need to decide ahead of time whether the
form should target rich client or browser-based users. If you do choose to design a form
specifically for the InfoPath client (and therefore not browser enabled), InfoPath exposes an
extended set of features. Controls such as the Combo Box, User Roles, showing message boxes
through a rule action, and the custom task pane are some of the extra features you'll see.
There are classes of features that don't work with Forms Services: unsupported and incompatible.
If you include unsupported features (such as message boxes and custom task panes), you can
still use the form template in Forms Services, but those features are nonfunctional. Incompatible
features, in contrast, will fail when published to Forms Services.
How do we know which features are compatible and which are not? The Design Checker, shown
in Figure 4, is a new task pane that communicates potential design problems to the developer.
For this example, we designed a complex form that is not browser enabled. To make it compatible
with Forms Services, we clicked on the Change Compatibility Settings link and modified the
setting that enables the form to work in either a browser or in InfoPath. The Design Checker
displays errors because our initial design included InfoPath client-only features, such as two
Master/Detail controls that are incompatible with browser-enabled forms. When designing a
browser-compatible form template, such features are not even available in the user interface. To
begin fixing the errors, you simply click on the error to jump to the invalid control. If an error is
not on a control, InfoPath gives instructions on how to proceed.

Figure 4 Design Checker Task Pane

In addition to browser enabling the form, we also specified our server's name in the compatibility
settings so we can enable the Verify on server option in the Design Checker. This option actually
uses Forms Services to verify the integrity of the form template being designed. In this case, the
server validation found an unsupported expression that InfoPath verification didn't catch. The
Design Checker will also list browser optimizations when it detects form templates that may
induce performance lags. Unlike for the InfoPath client application, performance optimization for
InfoPath Forms Services is critical when tens of thousands of users could be filling out your forms
simultaneously.
The Design Checker also serves other purposes. When you're using a form template importer like
Word or Excel, the Design Checker will show importer warnings when, for example, unsupported
features are removed. Additionally, the Design Checker reveals incompatibilities in form
templates that must be backward-compatible with InfoPath 2003.

Template Parts
Custom controls were introduced with InfoPath 2003 Service Pack 1 (SP1), but support was
limited to ActiveX controls. Since ActiveX controls have been around for over 10 years, there are
plenty to choose from. But only controls safe for scripting and initialization can be used in
InfoPath form templates. And even those that are safe may not work correctly in InfoPath. If you
don't find an existing ActiveX control that fits your needs, you can always create your own. This is
time consuming, though, and requires in-depth knowledge of ActiveX technologies.
Luckily, InfoPath 2007 introduces Template Parts, which let you build custom components without
code. As the name implies, Template Parts allow you to reuse parts of one form template in other
form templates without having to rebuild each one from scratch. Let's say you have an XML
schema that includes customer information such as name, address, phone number, and so on.
You want to build a set of forms all based on the customer section of the schema without having
to recreate the controls and schema that pertain to the customer information in each form
template. With InfoPath 2007 you don't have to recreate all those controls.
When you design a form template in InfoPath 2007, you now have the option to create a Template
Part instead of a form template, as the new Design a Form dialog in Figure 1 shows. You can
create a blank Template Part just as you'd create a blank form template, or you can base your
Template Part on an XML schema that includes customer information.
Once you specify Template Part in the Design a Form dialog, InfoPath opens in design mode. From
here, the process of creating your Template Part is almost exactly the same as creating a form
template. The only difference, as when creating a browser-enabled form template, is that not all
features are available. Those features not supported in Template Parts simply aren't available in
the user interface in design mode. For example, you can't add custom code to Template Parts so
the Programming menu item is not available on the Tools menu.
Once you've created a Template Part based on the XML schema that contains customer
information, you can insert controls that are bound to the customer information in the schema.
And just as you normally would when designing a form template, you can add data validation,
rules, calculated default values, and data connections. When you're finished, you save it as you
normally would. This creates a file with an .xtp file name extension. (The .xtp file is similar to
the .xsn file created when you save a form template.)
Before you can use your Template Part in form templates, you must install it into the InfoPath
Controls task pane in design mode using the Add or Remove Custom Controls wizard. After the
Template Part is installed, it is available in your Controls task pane just like any of the built-in
InfoPath controls, and you can insert it into as many form templates as you wish.
As with the built-in InfoPath controls, when inserting a Template Part into a form template, the
schema structure that pertains to your new control will be created automatically in the form
template (if you have selected the Automatically create data source option in the Controls task
pane) or you can choose to bind your control to an existing schema structure. Any of the features
you added to your Template Part earlier, such as data validation or rules, will be automatically
added to your form template. Template Parts not only enable you to create your own custom
controls without writing code, they also give you a way to share parts of a form template across
multiple form templates, thus saving much time and effort.

Document Information Panel

One of the main benefits of using InfoPath to fill out forms is its ease of use. As a form designer,
you can quickly create form templates that provide a rich user experience and are based on
common XML technologies. Users get the familiar experience of using an Office application along
with the straightforward form-filling experience provided by InfoPath.
With InfoPath 2007 you can take advantage of this form-filling experience in your own
applications. You might want to convert an existing application to use InfoPath for filling out forms
without having to retrain your users. Or maybe you want to create a form repository tool that
enables users to fill out forms and quickly find existing forms within the same interface. In either
case, you probably don't want to create a new form editing tool from scratch.
Let's look at how InfoPath is hosted in other Office applications. The 2007 Office system
introduces a new XML-based file format that is used in the core Office applicationsWord, Excel,
and PowerPoint. Since InfoPath can be used to edit XML-based forms, it makes sense that InfoPath
can also be used to edit some of the XML in this new Office file format.
Word, Excel, and PowerPoint 2007 all include a new Document Information Panel, which is used to
edit document properties in much the same way as you'd use a properties dialog in Office 2003.
However, since the document properties are stored as XML, it makes more sense to use InfoPath
for editing these properties.Figure 5 shows the standard Document Information Panel in Word
2007. As you may be able to tell, this is simply an InfoPath form hosted inside a Word document.
At first, you may think this is no different from using the old properties dialog. But not only do you
get certain InfoPath features such as data validation, you also have the ability to customize the
user experience for editing document properties. Since the Document Information Panel is
hosting InfoPath, you can now create your own form templates to edit the document property
data.

Figure 5 Word Document Information Panel and InfoPath Form

Hosting the InfoPath Form Control

Now let's talk about how you can put InfoPath to use in your own applications. Doing so can be
quite simple. InfoPath 2007 packages its form-filling component as an ActiveX control you can

host in your app. Support for hosting InfoPath in both managed and unmanaged code is provided
so you can choose the technology you want to use to build your application. Obviously, hosting
any ActiveX control in an unmanaged application is more complicated than in a managed app.
However, if you already know how to implement an ActiveX control host application, doing so
with the InfoPath ActiveX control is no different.
Let's take a brief look at how to host InfoPath in a managed Windows-based application using C#.
(Any InfoPath-specific concepts we discuss can just as easily be applied to unmanaged
applications and to other managed languages.)
After stepping through the New Project wizard in Visual Studio 2005 to create your Windowsbased application in C#, you'll need to add the InfoPath form control to the Visual Studio toolbox
before you can use it. To do so, click on Choose Toolbox Items from the Tools menu, click on the
.NET Framework Components tab, and then locate the component named FormControl in the
Microsoft.Office.InfoPath namespace. (In unmanaged code, the FormControl class is equivalent to
the IInfoPathEditor interface.) Once the InfoPath form control is in your toolbox, you can add it to
your Windows form just as you would with any other control.
If you build and run your application at this point, the InfoPath form control will be instantiated
but it won't do anything useful. Most likely you'll want the InfoPath form control in your
application to load a form. If you look at the FormControl object in the Object Browser in Visual
Studio 2005, you'll see that the InfoPath form control provides a number of useful methods and
properties. Probably the most important methods available are the ones that let you load a form
into the InfoPath controlOpen and NewFromFormTemplate.For the purposes of this simple
example we'll use one of the two NewFromFormTemplate methodsthe one that takes the URI of
the InfoPath form template you want to load as a string parameter. For example, if you want to
load a form template containing customer information, you could do so by adding the following
code:
formControl1.NewFromFormTemplate(@"\\mysharelocation\customerInformation.xsn");

Alternatively, if you want to load an existing form, you could use the open method, like so:
formControl1.Open(@"\\mysharelocation\myForm.xml");

Note that the XML file you pass to the open method must be a valid InfoPath form.
The XmlForm property is equally useful. (In unmanaged code it is equivalent to the
get_XDocument method on the IInfoPathEditor interface.) This property gives you access to the
entire InfoPath object model for the form. Certain objects in the InfoPath object model, such as
the Application and Window objects, aren't available when hosting the InfoPath control. These
objects pertain to the InfoPath client application, so have no meaning when hosting the InfoPath
form control.
The methods and properties available on the FormControl object give you a few ways to manage
and interact with the hosted InfoPath form control. But this object obviously doesn't provide full
control over the hosted form. For example, how do you make text bold or italic in the form? How
do you insert a table into a RichText Box control? These and other features that are available in
the InfoPath client application through the user interface aren't available through the FormControl
object. However, you can access virtually all of these features from your own applications, using
the IOleCommandTarget interface.
In unmanaged code, using IOleCommandTarget is straightforward. You simply obtain a pointer to
the interface from the hosted control and then pass a command to the Exec method (Likewise,
you can call the QueryStatus method to see if a command is currently supported.) In managed

code, you must use COM interop to access the interface. To find a list of all the available
commands simply look at the FormControlCommandIds.CommandIds static helper class in the
Microsoft.Office.InfoPath namespace. (In the Object Browser in Visual Studio, the
FormControlCommandIds.CommandIds is listed under the Microsoft.Office.InfoPath.FormControl
namespace. There are literally hundreds of commands that enable you to control hosted forms
from within your application.
With the support for hosting InfoPath in managed applications, you can create a simple hosting
application in literally just a few minutes. You can also host the InfoPath Forms Services
component. A form in the browser can be rendered by hosting the XmlFormView ASP.NET control
in an .aspx page. (The XmlFormView class is defined by the Microsoft.Office.InfoPath.Server.dll
assembly in the Controls namespace.) In fact, when you fill out a form in the Web browser that
isn't hosted, you're really looking at a mostly empty .aspx page that hosts the XmlFormView
control.
To use this control in your own ASP.NET page, your page must live on a SharePoint Server 2007
server that is running Forms Services. Then you can use Visual Studio 2005 to add the control to
the Toolbox (as described earlier for the InfoPath Form Control) and insert it into the Visual Studio
design surface of your ASP.NET Web site project. As you code against the XmlFormView control,
you might notice that the entire InfoPath object model is available to the host page. This is a
faade, though, because only a strict subset of the object model is actually allowed to be called
by the hosted page. For example, the data source is accessible through the MainDataSource
property, but accessing the form's Errors collection is restricted. An exception is thrown when
calling any restricted properties and methods at run time.
Hosting a Web Form in the browser is another exciting prospect for your InfoPath forms. Not only
can you reach out to users without InfoPath, you can also integrate the InfoPath form-filling
experience into your own Web pages while maintaining the integrity of your Web site's
appearance.

Importing and Exporting Forms

InfoPath 2007 provides more support for exporting data to other applications. InfoPath 2003 let
you export forms to a Web page or to an Excel spreadsheet. InfoPath 2003 did allow you to export
a form to an Excel spreadsheet but now there is more extensive support for exporting your data.
And InfoPath allows you to import forms as well. The framework for building form importers was
available in InfoPath 2003 SP1, but only now does InfoPath ship with built-in importers. With
InfoPath 2007, you can import forms from either Word or Excel. When you import a form, an
InfoPath form template is created which you can then customize to meet your needs. You may be
thinking that you can already transform a Word or Excel form into an InfoPath form by copying
and pasting the form into InfoPath. However, importing has a huge advantage over copy and
paste: the built-in importers will create controls and schema for you automatically. For example,
suppose your Word form contains text, as shown in the following:
Enter your name: _________________________

In this case, users know they are supposed to enter their name in the underlined area of the
document. InfoPath will detect this construct and create a Textbox control in the view. That
Textbox control will be bound to a field element in the schema. The fact that the built-in InfoPath
importers create controls and schema will certainly save you lots of time when you're migrating
forms from Word and Excel to InfoPath.

InfoPath 2007 also provides tight integration with Outlook 2007. You can publish a form template
in InfoPath 2007 to a list of e-mail recipients. This gives you a quick way to distribute a form
template to accomplish simple tasks such as gathering survey data. When Outlook 2007 users
receive the form, they can fill it out from within Outlook without having to open the InfoPath client
application. Figure 6 shows an InfoPath e-mail form that will collect survey data.

Figure 6 InfoPath E-Mail Form

Outlook 2007 supports creating InfoPath form folders to store submitted forms and includes rules
for moving specific InfoPath forms to those folders. Using InfoPath form folders along with
InfoPath property promotion, the data from the submitted forms are visible as columns in each
form folder. Therefore, you can quickly see the data contained within the submitted forms without
having to open each individual form. Since these folders are typical Outlook folders, you can sort
and group information, which lets you make decisions in less time.

Managed Object Model

If you wrote managed code behind a form in InfoPath 2003 SP1, you're accustomed to hooking up
events using attributed methods and the thisXDocument and thisApplication objects to access
the bulk of the object model. In InfoPath 2007, the API is much improved. To hook up an event,
simply use the .NET-style event assignment in the InternalStartup method of your form code class
(this code and the associated event handler can also be auto-generated through the Tools |
Programming menu flyout):
EventManager.FormEvents.Loading += new LoadingEventHandler(FormEvents_Loading);

There have been some name changes: the old OnLoad event is now named Loading, and all XML
events have been renamed to Changing, Validating, and Changed. Also, the InfoPath 2007 data
source is exposed in code as an XPathNavigator instead of MSXML's XML document and node
interfaces. This change provides a performance-oriented cursor-based approach to working with
the underlying form data. (To get the main data source navigator, use
this.MainDataSource.CreateNavigator.)

Many objects that were grouped in thisXDocument are now inherited members, and some even
sport updated names (such as the MainDataSource member). A few others include CurrentView,
DataConnections, DataSources, Errors, and SignedDataBlocks. One of the more popular methods
to use in form code was to display a dialog using:
thisXDocument.UI.Alert("message")

Now you'd use the System.Windows.Forms namespace's MessageBox class. By calling the static
method Show off of the MessageBox class, you can show the same dialog as the old Alert
method. Better yet, Show also has overrides to use message box captions, buttons, and even a
custom icon.
Best of all, the InfoPath object model abides by the design-once philosophy we talked about
earlier: the code you write behind your form can be used on both the client and server.

Visual Studio Integration

To help rapid development of sophisticated form templates, InfoPath takes advantage of the
Visual Studio 2005 environment. Since Visual Studio is the platform of choice for Windows-based
development, it is a smooth transition to InfoPath.
For InfoPath 2003, Microsoft Script Editor (MSE) was the included development environment. But
its usefulness was limited to writing JScript and VBScript code. Without Visual Studio .NET 2003
and the associated InfoPath Toolkit, you could not easily write managed code behind an InfoPath
form. For InfoPath 2007, Visual Studio Tools for Applications supplements MSE as the environment
for writing your managed form code. It will be familiar if you've used Visual Studio and it includes
many of the core features you need: IntelliSense, an object browser, and a full-featured
debugger. Simply run the project in Visual Studio Tools for Applications and you'll be debugging
your form in InfoPath's preview mode within seconds.
To meld the development of the form code with the designing of the form template, you can use
Visual Studio 2005 Tools for the 2007 Microsoft Office system, which takes the InfoPath design
mode and integrates it directly into the Visual Studio IDE. The full lifecycle of designing a new (or
existing) form, inserting controls, modifying data sources, and sprinkling features such as
conditional formatting, data validation, and rules all take place in Visual Studio. Previewing and
actually filling out the form, however, are left to InfoPath. Designing a form with Visual Studio
Tools for Office is shown in Figure 7.

Figure 7 Designing an InfoPath Form with Visual Studio Tools for Office
Besides the integrated design environment, there are other benefits to using Visual Studio Tools
for Office. They include being able to use multiple simultaneously visible task panes, the Visual
Studio Find and Replace functionality, and taking advantage of plug-ins such as Visual SourceSafe
for source code control when collaborating in a team setting.
The topics we've discussed are just a few of the highlights of InfoPath 2007. We hope this brief
introduction will spark your interest and will prompt you to explore InfoPath 2007 further. If you
are new to InfoPath or would like more detailed information about designing forms, see the
InfoPath Web site atoffice.microsoft.com. Tune in to the InfoPath Team Blog
at blogs.msdn.com/infopath for info from the product team.

Use InfoPath e-mail forms in Outlook

If you already use Microsoft Office InfoPath forms for tasks like submitting weekly status reports, and if you
use Microsoft Office Outlook 2007 to manage e-mail messages, InfoPath e-mail forms can help streamline the
processes that you use to collaborate and share data. That is because you can open, fill out, and submit
InfoPath forms from within Office Outlook 2007, without having to open InfoPath. If you receive an InfoPath
e-mail form, you can reply to it, forward it, and store it just as you would with any other items in Office
Outlook 2007.

In this article
Prerequisites for using InfoPath e-mail forms
Collect data from others by using an InfoPath e-mail form
Submit your own data by using an InfoPath e-mail form

Prerequisites for using InfoPath e-mail

forms
Before you begin, you should read the following prerequisites for using InfoPath e-mail forms. If the following
items are true in your organization, you can use InfoPath e-mail forms to send or receive form data.
Installation prerequisites To send or receive InfoPath e-mail forms in Microsoft Office Outlook 2007,
Microsoft Office InfoPath 2007 must be installed on your computer, and Office Outlook 2007 must be
configured to send and receive InfoPath e-mail forms. If you have these programs installed on your computer,
and Office Outlook 2007 is configured to send InfoPath e-mail forms, but the same is not true for recipients of
your InfoPath e-mail forms, the forms that you send will appear to those recipients as attachments to e-mail
messages. The recipients can then save the attached forms and open them by using InfoPath. Office Outlook
2007 is configured to send and receive InfoPath e-mail forms by default. To turn InfoPath e-mail forms on or
off, in the Options dialog box in Office Outlook 2007, click Advanced Options on the Other tab, and then
select or clear the Enable InfoPath E-Mail Forms check box in the Advanced Options dialog box.
Availability of forms If you want users to fill out InfoPath e-mail forms and submit the data back to you,
and the form's associated form template is not stored in a shared location that your users can access, you can
include the form template with the InfoPath e-mail form by clicking the Include form template option in
the Mail Options task pane. The task pane appears when you forward an InfoPath e-mail form or reply to it, or
when you send it by clickingSubmit on the form. Alternatively, you can send a read-only version of the form.

Installation prerequisites for recipients If the recipients of your InfoPath e-mail forms do not have
Microsoft Office Outlook 2007 and Microsoft Office InfoPath 2007 installed and configured to use InfoPath email forms, they will receive an e-mail message that contains an HTML representation of the default form
view, and an InfoPath form will be attached to the e-mail message. If the recipients have an earlier version of
InfoPath installed, and the form contains backward-compatible features, they can save the attached form file
and open it by using the earlier version of InfoPath.
NOTE When the InfoPath e-mail forms that you send to others are filled out and sent back to you, you can

review the data from those forms in various ways in Office Outlook 2007. For example, you can view the data
by using a customized view of an InfoPath Forms folder, which enables you to view the form data without
opening the forms themselves. You can also merge multiple InfoPath e-mail forms into a single form to
analyze or compare data, or export the data from one or more InfoPath e-mail forms to Microsoft Office Excel
2007. Find more information about these tasks in the See Also section.
Top of Page

Collect data from others by using

an InfoPath e-mail form
1.

On the File menu, point to New, and then click Choose InfoPath Form.

2.

In the Choose InfoPath Form dialog box, double-click the form that you want.

3.

In the InfoPath Form: Form Name window, click Forward.

4.

Enter recipient e-mail addresses in the To and Cc boxes. Separate names with a semicolon (;).
NOTE The Bcc box does not appear by default. To add an e-mail address to the Bcc box, click To or Cc, and

then in the dialog box that appears, type the e-mail address in the Bcc box.
5.
In the Subject box, type a new subject for the message.

6.

In the Introduction box, type explanatory text about the InfoPath e-mail form.

7.

In the Mail Options task pane, do one of the following:

To send a version of the form that recipients can use to fill out and submit data,
click Editable form.
NOTE If the form template for the form is not located in a shared location that other users can access, such as a

network folder or a Windows SharePoint Services 3.0 site, select the Include form templatecheck box.
To send a read-only version of the form, click Read-only snapshot.

8.

Click Send.
NOTE Because you are sending an InfoPath e-mail form to collect data from others, you do not need to type

any data in the InfoPath e-mail form fields before you send the form.
Top of Page

Submit your own data by using an

InfoPath e-mail form
1.

On the File menu, point to New, and then click Choose InfoPath Form.

2.

In the Choose InfoPath Form dialog box, click the form that you want.

3.

In the InfoPath Form: Form Name window, type data into the InfoPath e-mail form.
TIP Filling out an InfoPath e-mail form is just like filling out a form in InfoPath. For example, if the form

contains more than one view, you can switch views by clicking the View menu on the form and then selecting
the view that you want. Find more information about filling out InfoPath forms in the See Also section.
4.
Click Submit, and then in the InfoPath Form: Form Name dialog box, type the recipient e-mail
addresses in the To, Cc, or Bcc boxes. Separate names with a semicolon (;).
NOTE If the form template designer has defined a custom submit action, the data is automatically sent.

5.

In the Subject box, type a new subject for the message.

6.

In the large box at the bottom of the dialog box, type explanatory text about the InfoPath e-mail form.

7.

Click Send.

8.

To save a copy of the form that you just sent to the active folder, click Save on the File menu.

Mel Balsamo
Using InfoPath E-mail Forms to Communicate with External Users
Gregs blog post provided brief guidelines on how to create form templates with different versions. One is a
restricted version for public-use, i.e. for external users; the other is a version for private use. The private version
may contain some additional controls that allow you to do more with your forms, such as submitting them to a
SharePoint document library.
This technique gives us the power to use InfoPath forms to capture offline e-mailed data for centralized SharePoint
upload. We can email forms back-and-forth, to and from external users (sometimes offline or disconnected), and at
the same time, manage those forms in private locations such as a SharePoint site. We need to make sure that the
form data in both the public and the private locations are in-sync.
This blog post details the steps to setup a sample email form template with two different versions: Public and
Private.
Heres a diagram of the scenario were trying to accomplish:

1. You email the form template (XSN) file to an external user (Public version Ver. 1).
2. External user (sometimes offline) opens the form template, fills it out and emails back to you.
3. You receive the form (XML) and open it with the higher version of the form template (Private version Ver. 2).
Note that you may receive a warning message that the form template associated with the form has a higher
version than the one stored on your computer. Clicking Yes will open the form with your latest version.
4. You submit the form to your SharePoint document library.
5. You open the form from SharePoint, edit it and email it back to the user.
6. User receives the form, accepts the changes, re-edits and re-emails back to you.

Note that the user may also receive a warning message about the form template version. Clicking Yes will allow
user to open the latest form.
7. You receive the form and re-submit it to SharePoint.
Sounds interesting? Lets get started

REQUIREMENTS:

InfoPath 2007

Outlook 2007

SharePoint Library

PUBLIC VERSION
1. Add the following fields to your main Data Source

Make the EmailAddress field required, so we know where to send the form back.
2. Add a layout table in your template, and drag the myFields node onto your table as Controls in Layout Table.
Expand your controls as necessary to make them fit in your table.
3. Double-click on your Date field to open its properties.
a. Under the Data tab, click Format. Select any format for the time such as:

b. Click OK.
c. Back in the Data tab, click on the fx icon beside the Value field, and enter the now() function in the formula box.

This will ensure that well have a unique date value every time we fill out a form the first time. We will specify this
unique value as the form filename in our SharePoint library later.
d. Click OK to close all the dialog boxes.
4. Allow the Comments field to display multi-line in the Comments field properties > Display tab, just so theres
more space for users to fill it out.

Your form template should look something similar to this:

5. Add a Submit data connection.

a. Go to Tools > Data Connections, click Add.
b. In the Data Connection Wizard, select Submit data > As an email message.
c. Specify an email address where you want your external users to send the form to; i.e.
<YourEmail>@<YourCompany.com>.
d. You can enter any value as the email subject or select an existing field in your form template. In this example,
we will use our Name field as the Subject.

e. Click Next.
f. Select the option Send the form data as an attachment.
g. For the attachment name, combine the Name and the Date values. Click on the fx button beside the Attachment
Name field, and enter concat formula as seen in the following image, making sure that the underlined fields are
from your main data source:

h. Click OK (no need to attach the form template in the email), Next, then Finish to exit out of the wizard.
6. Add and configure a Submit button.
a. Add a button at the bottom of your table, and double-click to open its properties.
b. In the Button Properties windows General tab, select Submit in the Action dropdown, and click Submit Options.
c. Check the box Allow users to submit this form > Email > Email Submit.
d. Click the Advanced button to expand the window, and select Close the form in the After submit dropdown:

7. Make the form restricted for external users.

a. Go to Tools > Form Options > Security and Trust.
b. Uncheck the box for Automatically determine security level, and select Restricted:

c. Click OK.

8. Save the form template as PublicEmailForm.xsn.

Heres how our public email form template looks like:

PRIVATE VERSION
Next, we will design our private form template. It will have the same fields, so we can just modify our public form
template.
1. While the public template is opened in Design mode, go to File > Save As and save it as PrivateEmailForm.xsn
(to make sure that we are not working on the public version).
2. Modify the Email Submit data connection.
a. Go to Tools > Data Connections and modify Email Submit.
b. Click on the fx button next to the To field and insert the EmailAddress field. This field will contain the external
users email address (where we wish to send the form back to).

c. Click Next twice, and then Finish to save your changes.

3. Configure the SharePoint Submit data connection.
a. In the Data Connections wizard, click Add to add another data connection.
b. Select Submit data > Next > To a document library on a SharePoint site > Next.
For the purposes of this tutorial, we will submit to a SharePoint document library named EmailFormsLibrary. This
library should not exist yet. We will create it later when we publish our private form template.
c. Enter the URL to your EmailFormsLibrary SharePoint library, i.e. http://<SharePointSite>/EmailFormsLibrary/
d. For the file name, click on the fx button and select Date from your main data source. Again, we are making sure
that our form file name is unique each time we submit a form to our SharePoint Library the first time; thus
selecting Date which uses the now() function.
e. Check the box that allows overwrite if file exists.

f. Click Next, leave the name as SharePoint Library Submit, and then click Finish.
g. Exit out of the Data Connections wizard by clicking Close.
4. Configure the submit buttons.
Note that we now have two Submit data connections, and we therefore need to use two buttons: one that submits
to our SharePoint library, and another to email the form back to the external user. We also need to submit using
rules and specify which Submit data connection to use.
a. Double-click on the existing Submit button to open its properties.
b. In the Action dropdown, select Rules and Custom Code.
c. Label the button Submit to SharePoint and click on Rules.
d. In the Rules dialog, click Add.
e. Name your rule SharePoint Submit and click on Add Action. The action would be to submit using the SharePoint
Library Submit data connection:

f. Click OK three times to close the dialog boxes.

g. In the Controls task pane, select Button to add another button just beside the SharePoint Submit button, and
double-click to open its properties.
h. Label it as Email External User and click Rules.
i. In the Rules dialog, click Add.
j. Name your rule Email External User and click on Add Action. The action would be to submit using the Email
Submit data connection:

k. Click OK three times to close the dialog boxes.

5. Since weve already configured our submit function to use rules instead of the built-in submit feature, we can
now disable that. In Tools > Submit Options, uncheck the box that allows users to submit the form, and click OK.
6. Set the security mode.
Since this form template is a private version, meaning it is used internally by users in your network/domain, we
can allow the form to access content from the domain in which it is located.
a. Go to Tools > Form Options > Security and Trust and select Domain (or Full Trust).

b. Click OK.
Heres how our private email form template looks like:

7. Save your PrivateEmailForm.xsn form template and then close it.

MANIPULATING FORM VERSIONS

Heres where it can get a bit complicated. We want to manipulate InfoPath to think that our Public and Private
forms are one-and-the-same, when in fact, they are two different forms. To make this happen, first, we need to
give these two form templates the same ID. This is considered as a Class A trick.
As mentioned in Gregs blog post:
The ID is used to determine which template a form will be opened with. But this ID is dynamic. As the Name
changes, so does the ID. And every time you do a Save As, the Name and ID are changed.
A. Lets start with our public form template:
1. Open PublicEmailForm is InfoPath Design mode.
2. Go to File > Properties. Here you will find fields for the Name, ID, and Description.

3. To make things simpler and easier to understand, lets remove the date and time stamp in the templates URN:

4. Click OK then File > Save.

5. Since this template is what we will email our external users with, we need to save it with a different name.
a. Go to File > Save As and name it EmailForm.xsn.
b. In File > Properties, notice that the Name and ID changed.

c. Once again, remove the date and timestamps in the URN to avoid confusion.

d. Click OK.
e. Go to Tools > Form Options > Versioning. Notice that the Version number is something like 1.0.0.x, where x is a
number that automatically increments as we make changes to our template. We can leave it this way for our public
email template.
f. Click OK, then File > Save.
6. Weve already saved the public version as EmailForm; close it, and then send it to an external user by attaching
the form template in the Outlook message.

B. Next, our private form template:

1. Open PrivateEmailForm.xsn in InfoPath Design mode.
2. We need to make sure that our private template will have a higher version number than the public one.
a. Go to Tools > Form Options > Versioning.
b. Change the Version Number from 1.0.0.x to 1.0.1.x. This way, when we open the forms (XML) in our local
machine, they will open with the higher template version, which is the private one. Click OK.
3. Go to File > Properties:

4. Remove the date and time stamp in the templates URN:

5. Click OK then File > Save.

6. This time, we will overwrite our previous EmailForm.xsn with this private form template.
a. Go to File > Save As > EmailForm > Overwrite.
b. In File > Properties, the Name and the ID once again becomes:

c. Remove the date and time stamps, click OK then Save.

Notice that this template (private version) has the same ID as the one that we sent to our external user (public
version). Dont be confused, this template has a higher version number than the one already sent. As we know,
forms will open with the higher version template.

C. Publish the private version to a SharePoint library

1. In EmailForm.xsns (previously PrivateEmailForm) File menu, click Publish.
2. Select to publish to a SharePoint server with or without InfoPath Forms Services, and click Next.
3. Enter the URL to your SharePoint site and click Next.
4. Select to create a Document Library > Next.
5. Select Create a new document library > Next.
6. Enter a name for your document library (remember that we wish to submit our forms to a library called
EmailFormsLibrary). Click Next.
7. Promote some or all of the fields in your form as columns:

8. Click Next, then Publish, then Close.

9. Close InfoPath.

SEE IT IN ACTION
1. Have an external user fill out and submit the public template you initially emailed.

2. You will receive the form (XML) in your email.

3. In Outlook, click Open Form. It will open with the private version of the template.

4. Make some changes in the form, such as editing the Comments, and click the SharePoint Submit button.

5. Close the form in Outlook. If you get a warning asking you if you wish to save the form, select No.
6. Verify that the form is submitted to your SharePoint document library.

7. Open the form from SharePoint, make some changes, and email it back to the external user by clicking the
Email External User button.

8. The external user will receive the modified XML and may receive a warning that the form template associated
with the form contains a higher version. Clicking No will allow the user to open the form in Outlook using the public
version.

9. The external user then modifies the form and emails it back to you by clicking the Submit button. Once again, if
you open the received XML in Outlook, it will open with the private version:

10. Re-submit the form to your SharePoint library to make sure you are keeping the latest XML version. It will
overwrite the existing XML in your SharePoint library:

At this point, we should have three form templates in our machine: PublicEmailForm, PrivateEmailForm, and
EmailForm. We are only concerned about EmailForm, as this form template contains the unique Name and ID that
we wish to send back-and-forth, to and from our external users, and manage our SharePoint library forms with.
The PublicEmailForm and the PrivateEmailForm are just temporary placeholders. For instance, if you wish to send a
public version to another external user, we cant send them the latest EmailForm that we have (since its supposed
to be the private version). To do this, we need to open PublicEmailForm in InfoPath Design mode, and re-save
(overwrite) it as EmailForm. After sending to the external user/s, open PrivateEmailForm in Design mode and resave (overwrite) it as EmailForm, and then re-publish to the same SharePoint document library.

Youll realize that were just manipulating the same form template in terms of which version will be sent to public,
and which version should open in our machine.
Once you get the hang of this, it will be easy for you to manage your form data and keep them in-sync no matter
where you publish your forms.

Create a SharePoint Form with InfoPath Designer

In This Chapter

Design a SharePoint Form Using the Blank Form Template

Add Controls

Preview Your Form

Name Your Data Fields

Add Submit Options

Publish Your Form

Use Your Form in SharePoint

Create a Form Library from InfoPath

Design a SharePoint Form Using the SharePoint Form Library Template

This chapter shows you how to generate an InfoPath form for use in SharePoint. The following chapters
expand on the functionality and options available. This chapter serves as an end-to-end overall guide to
creating a form and publishing it to SharePoint. Other chapters may cover some details or steps in further
detail.

The first step to create SharePoint forms is to open InfoPath Designer. From there, you have a number of
options. When designing a new form, you have the following template options:
SharePoint List: Use this template to generate an interface for interacting with a SharePoint list. The
generated form can create the actual list in SharePoint.
SharePoint Form Library: Use this template to generate a form library that stores instances of your form from
user input. The content type of this form library is your form template.
E-mail: Use this template to generate a form that can be used within emails.
Blank Form: This is the base web browser form template used to generate SharePoint forms from scratch.
Blank Form (InfoPath Filler): This base client form template is used to generate forms that require users to
have InfoPath installed locally on their computers. The forms created using this template are not rendered in a
web browser.
Database: Use this template to quickly create a form based on a database table from Access or SQL Server.
Web Service: Use this template to generate a form that queries a web service for information.
XML or Schema: This template is used to easily replicate the data structure of an Extensible Markup
Language (XML) file or schema (XSD).
Data Connection File: Use this template to quickly generate a form that uses a data connection file stored in
SharePoint.
Convert Existing Form: The name is confusing because you would think this is used to convert an existing
InfoPath form, but this template actually uses converters to import Microsoft Word or Microsoft Excel
documents and convert them into InfoPath forms.
Document Information Panel: InfoPath now makes it easier to customize input into Office documents based
on SharePoint columns. Use this template to generate the data entry portion of a Microsoft Office document
that is stored within a SharePoint library and contains additional fields for user entry.
Blank 2010 Form: Use this form to create a web-based InfoPath 2010 form.

Blank 2010 Form (InfoPath Filler): Use this form to create a client-based InfoPath 2010 form. Users need
InfoPath 2010 installed locally on their computers.
NOTE
Throughout this book, the terms InfoPath form and SharePoint form may be used interchangeably. A
SharePoint form is essentially a web-enabled InfoPath form with the intention to be able to use the form in
SharePoint.

Design a SharePoint Form Using the Blank Form Template

Scenario/Problem:
You want to create a new form for user input to be used in SharePoint.
Solution: When you open InfoPath Designer 2013, you are automatically taken to the File, New page, as
shown in Figure 2.1. Either double-click Blank Form or select the Blank Form button and click the Design Form
button to create a new blank form.

FIGURE 2.1. The New page provides templates for designing new forms.
To design a simple form, follow these steps:
1.

Click the Click to Add Title text that appears and enter a title for the form.

2.

Click in the bottom section of the form where it states Add Tables.

3.

Click the Insert ribbon bar menu and select the Two-Column 4 table in the Tables section. This is a
layout table that assists in aligning the labels and controls on your form.

4.

Click the File menu and then click Save.

5.

Enter a name for the form file and click OK. This saves a local copy of the form.

We now have a base form to which we can start adding controls, as shown in Figure 2.2.

FIGURE 2.2. Entering a title and adding a layout table to a form produces a base form.

Add Controls
Scenario/Problem:
You need to add controls to a form for user entry.
Solution: Use the Controls section from the Home top ribbon bar.
To add controls to your form, follow these steps:
1.

Click the first Add Control cell in the layout table of the form.

2.

From the Home ribbon bar, locate the Controls section, as shown in Figure 2.3, and click Text Box.

FIGURE 2.3. The Controls section displays the available controls that you can insert onto your form.
3.

4.

Click the Add label in the cell to the left of the text box and enter a label for this entry. This tells the
user what information to enter into the text box.
Repeat these steps for the remaining rows in the layout table. Your form should look similar to Figure
2.4.

FIGURE 2.4. Adding labels and controls to the form provides the basis for user data entry.
5.

Click Save from the File menu to save your changes locally.

Preview Your Form

Scenario/Problem:

You need to see how your form works before you publish it to SharePoint.
Solution: With your form open and saved, there are three ways to preview the contents:

Press the F5 key.

Click the magnifying glass icon at the very top of the InfoPath Designer application.

Click the Preview Form button on the Home ribbon bar.

Your form will render in the InfoPath Filler version of the application, and you can view how it works there, as
shown in Figure 2.5.

FIGURE 2.5. Previewing your form shows you how the user will experience it.

Name Your Data Fields

Scenario/Problem:
You want to give your fields meaningful names. By default, when adding controls to your form, InfoPath names the fields
that will store the data generically (that is, Field1, Field2, and so on).
Solution: Change the name of the each field by either right-clicking each control or right-clicking the fields in the Fields
pane and selecting Properties. Enter a new name for the field name. Figure 2.6provides an example.

FIGURE 2.6. Naming your fields appropriately makes them easier to identify and manage.
NOTE
To be consistent, naming conventions should be established. Developers may use camel case (for example, lastName,
firstName), whereas business analysts might use Pascal case (for example, LastName, FirstName). There is no wrong or
right answer as long as everyone follows the same standards.

Add Submit Options

Scenario/Problem:
You need to enable users to submit the form after they fill it out.

Solution: From the File menu, select Info. On the Info page, click the Submit Form button.
Several options appear (as shown in Figure 2.7):

To Email: Submitting this form sends the contents in an email to a specified address.
To SharePoint Library: Submitting this form sends the contents as a saved instance of the form in a
SharePoint form library.
To Web Service: Submitting this form sends the form as XML to a web service.

To SharePoint Server Connection: Submitting this form uses a specified data connection stored in
SharePoint to submit the data.

Submit Options: If you are familiar with InfoPath 2010 or just want to take control of the submit
options, use this item menu to just get down to business.

FIGURE 2.7. Submit options determine where and how a completed form will be submitted.
For this scenario, select To SharePoint Library. The Data Connection Wizard appears. For the form to be
submitted to that form library, you need to have a data connection to the SharePoint library in the form.
You must specify a form library in SharePoint to submit the form; therefore, you might need to go to your
SharePoint site and create a new form library first. Enter the location of the form library in the Document Library
text entry. (Create a form library named SharePoint Forms for this example.)
TIP
You can create the form library right from InfoPath, as explained in a later section.

Now that some of the grunt work has been done, we come to the most important part of the submission to a
document library: the filename. If you notice, by default, the filename is Form. Thats great. If you leave it like
that, only one person can submit the form, it will be called Form.xsn in the form library, and no one ever can
submit the form again. Lets go home!
You need to specify something dynamic or unique about the form instance the user is submitting. This can be
tricky. You must define a formula to implement this correctly, and although we havent stepped through formulas
yet, we are forced to do at least one here.
The main ingredients for specifying the filename correctly deal with either entries in the form or entries in the
form combined with a system function such as the date.
For this example, we use the name the user entered in the form along with a date function. To do so, follow
these steps:
1.

Click the Function button to the right of the File Name text box. The Insert Formula dialog appears.

2.

Click the Insert Function button and select the concat function. Click OK. The function inserts three
spots for you to modify.

3.

Double-click the first entry and select the Name field from the field dialog that appears and click OK.

4.

Only select the next entry (dont double-click) and replace it with , including the quotation marks.

5.

Select the last entry and click the Insert Function button. Select Today from the Date category.

6.

Click OK.

7.

Remove the Double-Click to Insert Field text if it still appears. Click OK. Your formula should now look
similar to Figure 2.8.

FIGURE 2.8. Using a formula for the filename ensures that each instance is saved to a unique file.
8.

Click Next. If you are prompted for credentials, enter them accordingly.

9.

Click Finish to save the connection in the form.

TIP
If you use the now date function, the time component will be used in the filename, and even if you select to
overwrite existing files, the filename will never be the same (because the time changes every second). Avoid
this, if possible, because every update generates a new file.

Publish Your Form

Scenario/Problem:
You need to publish your form to SharePoint so that users can actually use it.
Solution: From the File menu, select Publish. On the Publish page, click the SharePoint Server button.
Clicking the SharePoint Server button, as shown in Figure 2.9, launches the Publishing Wizard. Follow these
steps to publish using the wizard:
1.
2.

Enter your SharePoint site address, as shown in Figure 2.10.

Click Next. The What Do You Want to Create or Modify? screen appears, as shown in Figure 2.11.
Leave the defaults.

3.

Click Next. The What Do You Want to Do? screen appears.

4.

Select Update the Form Template in an Existing Form Library.

5.

6.

Select the existing form library from the list, as shown in Figure 2.12. (To create a new form library see
the Create a Form Library from InfoPath section later in this chapter.)
Click Next. Click Next. Click Publish. The form is published to your SharePoint form library.

FIGURE 2.9. Clicking SharePoint Server launches the Publishing Wizard.

FIGURE 2.10. Enter the location of your SharePoint site.

FIGURE 2.11. Leave the defaults.

FIGURE 2.12. Select Update the Form Template in an Existing Form Library.
TIP
After you have stepped through the publish process once, you can facilitate future republishing of your form by
using the Quick Publish button.

Use Your Form in SharePoint

Scenario/Problem:
You need to test your published form in SharePoint.
Solution: Navigate to the form library you created in SharePoint and click the Add Document link.
Your form should render in the browser, as shown in Figure 2.13. Enter some values in the text boxes and click
the Submit button. An instance of the form is saved to your form library, as shown in Figure 2.14. Notice the
filename is using the formula we entered in our submit options.

FIGURE 2.13. Clicking the Add Document link opens a new instance of your form within the browser.

FIGURE 2.14. Submitting the form saves an instance of the form within the form library.
NOTE
When you use certain SharePoint site templates, such as the Blank Site template, the Enterprise features
might not be enabled. You need to make sure that Enterprise features are enabled to publish the form as a
browser-enabled form.
NOTE
The Save and Save As buttons shown here allow the user to save the form using a filename. This circumvents
the configured Submit button. Chapter 8, Submitting and Publishing in SharePoint, discusses how to change
the buttons that appear.

Create a Form Library from InfoPath

Scenario/Problem:
You need create a form library to publish and submit the form.

In the preceding section, you created the form library manually. By doing so, you understood where the
InfoPath form was going to be published and submitted. When starting from scratch with the Blank Form
template, you can use the Publish Form to a SharePoint Library option to create the form library and publish
the form, but you also need to enter submit options after the form has been published. Therefore, you need to
publish again after you have entered the submit options. It becomes a chicken-or-the-egg scenario.
Nonetheless, if you create a form using the Blank Form template, you may create the form library to house it
using the Publish Form to a SharePoint Library option, as follows:
1.

From the File menu, select Publish. On the Publish page, click SharePoint Server (Publish Form to a
SharePoint Library). The Publishing Wizard appears.

2.

Enter your main SharePoint URL or the full site address where you want the form library created and
click Next.

3.

Keep the defaults to create a form library and use the form in the web browser. Click Next.

4.

Select the Create a New Form Library option, as shown in Figure 2.15, and click Next.

FIGURE 2.15. Selecting the Create a New Form Library option allows you to create the form library from
InfoPath.
5.

Enter the name of the new form library and a description on the next wizard dialog and click Next.

6.

Click Next on the fields selection dialog.

7.

Verify the information and click Publish.

Design a SharePoint Form Using the SharePoint Form Library

Template
Scenario/Problem:
You want to use the SharePoint Form Library template to create a new form for user input in SharePoint.
Solution: From the File menu, select New. On the New page, click the SharePoint Form Library template
button, and click the Design Form button.
The SharePoint Form Library template provides you with additional starting points, including two subheadings
and tables, as shown in Figure 2.16.

FIGURE 2.16. The SharePoint Form Library template provides more starting material for when youre designing
a new form.
TIP
The SharePoint Form Library template is a glorified version of the Blank Form template.
So, now you can use this template and apply the same techniques described earlier in this chapter to publish
the form to SharePoint. However, you still need to create a form library and configure the submit options.