InfoPath 12 - Tudor Toma

Using InfoPath e-mail forms

Tudor_Toma — Wed, 22 Feb 2006 13:15:00 GMT

First I’d 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 I’ll be using from now on in my blog. In my first post I talk about the benefits of browser-enabled forms. I’d 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 we’ve 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 J. 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. Let’s walk thru a short scenario using InfoPath e-mail forms.

Let’s 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 I’ve completed it as a team member and I’m 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 I’m switching back to being the data collector. I’m 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, I’m 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 I’ve 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 I’ve 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?

We’ve seen how I’ve 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 you’d just use regular e-mail
The data collection is done ad-hoc – there’s 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 you’ve 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 e-mail 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 I’ve 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. I’ll follow up shortly with other posts on new InfoPath features. Stay tuned! I’d also love to hear your thoughts and feedback.

My overview of InfoPath browser-based forms

Tudor_Toma — Tue, 13 Dec 2005 13:24:00 GMT

This is my first blog on InfoPath 12 so please allow me to introduce myself. I’ve started in Microsoft as a developer on FoxPro. If anyone still remembers the database container and the client connectivity, those are features I contributed to many years ago. Later on I moved to program management and worked on the` data access stack in the early days of odbc, oledb, and ado. I’ve always been passionate with data processing so, about five years ago, I’ve been super excited to participate in jump-starting an incubation project for authoring generic xml. That project grew into InfoPath 2003, then SP1, and now the brand new InfoPath v2 in Office 12.

After we shipped InfoPath 2003, we’ve surveyed InfoPath users and asked them for the most important feature round-outs they’d like to see in the product. In SP1 we’ve addressed 9 out of the top 10 requests. However we couldn’t address request #1 which was filling out InfoPath forms in the browser. This feature is now available in InfoPath 12! I think the best use of my first post on InfoPath 12 is to give you an insight into browser forms and share some of my thoughts on this feature.

One goal for InfoPath 12 has been to let users design a form once for both the rich client and the browser. Informally we call this feature “design once”. This way the same form template basically addresses scenarios that require the richness of the InfoPath client and scenarios for browser form filling, with zero client footprint. Choosing between rich and reach forms used to be a dividing requirement for form developers. Now InfoPath provides what I think is a very elegant solution for it. In InfoPath 12 users building forms only need to check the “Web browser enabled” checkbox to create a “design once” form. (Yes, I will talk in a follow up post about the “Template Part” option J).

Our functionality goal for browser forms has been to provide a level of validation for the data entered via the browser than matches that of the data entered in the InfoPath rich client. In other words, for “design once” forms, the xml schema validation, rules, conditional formatting, and business logic apply the same way for both rich and browser forms. InfoPath makes sure that the quality of the data submitted by a form is the same, regardless of the client that has been used to fill it out.

The layout is very similar between the rich and the browser version of a form. As you may know, the InfoPath client uses html for the form layout, which makes it very similar to the same form rendered in the browser. I’ve included below a Loan Application form rendered in InfoPath and in IE. Notice the same in-doc UI for repeating items, the same controls, and the same table layout, which makes the forms virtually identical. One difference is the spellchecking in the InfoPath client, which represents an improvement over the browser form.

Here is the same Loan Application form rendered in Internet Explorer:

The value of zero footprint forms is not complete if they are not available virtually on any machine and on any platform. InfoPath 12 delivers ubiquity of form filling. Users are able to fill out forms in current versions of IE, Firefox, Safari, and Netscape. The form functionality and validation remains the same across all browsers. We’ve worked hard to provide true ubiquity of form filling in order to allow all users to participate in business-to-citizen scenarios such as banking, insurance, healthcare as well as in many government-to-citizen scenarios. I’ve included another version of the Loan form below, this time rendered in Firefox:

In addition to the browsers mentioned above, we are also providing InfoPath forms for mobile devices. The set of controls available for mobile browsers is more limited. However we expect to run most forms that are appropriate to being filled out on mobile devices. Here is the same Loan form as above rendered on a pda and on a smart phone:

I feel I’ve added a lot of screenshots for a first blog on InfoPath. To my defense, I’ve tried to make a visual statement on the ubiquity of browser forms and on their high layout fidelity in different browsers. I hope you found them valuable.

Finally, I wanted to mention a very important point. The first reaction of some customers when we show them the browser forms is to question the necessity of using the rich client: “If our users can access forms in the browser, with zero footprint, why would they ever need to run rich forms in InfoPath?” This question makes me think of my personal experience with Outlook Web Access. For me it provides a great experience for a browser mail client but I would never use it if I could work in Outlook. The rich functionality and offline caching are features I would never give up. I think InfoPath has a similar value proposition. It provides a smooth, self-contained form filling experience, with no server roundtrips. It gives you the ability to work on your forms offline. It also integrates with Outlook allowing you to route forms in email and store them in form-enabled folders, which become your local version of SharePoint form libraries. In addition, there are a few features, such as ActiveX controls and form rights management that work only in the InfoPath client.

This is my short dive into InfoPath 12 browser-based forms. I know I’ve mentioned a number of features without giving any details but I wanted to keep my posting scoped. I will follow up shortly with more product information. Please send me your comments and help me focus my upcoming posts on areas of most interest to you. Thanks and stay tuned!