Microsoft InfoPath 2010
The official blog of the Microsoft InfoPath team

  • Microsoft InfoPath 2010

    Use InfoPath 2010 with SharePoint 2010 Beta and Win an XBox360 Elite!


    Now that you have had time to download the SharePoint 2010 and Office 2010 Beta releases, we want to see some of the great solutions that you are working on.  To encourage you and foster some good-natured competition, we're opening up the contest that we started with the Technical Preview to all users of SharePoint 2010 and InfoPath 2010.

    What is the InfoPath team looking for?

    We want to see great examples of real-world solutions created using InfoPath and SharePoint 2010.  If you have a solution you're building to solve a business problem for yourself or a customer, and you're using SharePoint 2010 with InfoPath forms, we want to see it!  We'll use the videos you produce to understand what sort of solutions our customers create, to showcase best practices in our blog or at events, and to give you the recognition you deserve.  You could be an InfoPath star!

    Don't stop with the InfoPath form - we're looking for great examples of integration.  For example:

    • Use SharePoint workflows to complete your scenario
    • Generate Word documents from your InfoPath data using OOXML, and convert to other formats using Word Services
    • Interoperate with line of business systems using Business Connectivity Services
    • Create Web part portal pages that mash up forms and data using the InfoPath form web part
    • Be creative!  We want to see great examples of enterprise software that features InfoPath and SharePoint

    How do I win the Xbox? 

    • Build a real-world end to end application using InfoPath 2010 and Microsoft SharePoint Server 2010.
    • Download the Community Clips Recorder from 
    • Record a walkthrough of your solution, showing us how you used InfoPath forms and other Office technologies (5 minutes maximum)
    • Submit the finished video to us

    Contest is limited to eligible individuals as defined in the official contest rules (link below), and additional limitations may apply.  All submissions will be reviewed by the InfoPath team, and prizes will be awarded in several categories, including best overall solution, best video, and best bug. 

    Please note that only legal residents of the US and Canada are eligible for prizes.  However, we're eager to see videos from everyone, and we will showcase the best videos we receive, regardless of whether you are awarded a prize.

    Click here to read the Official Contest Rules.

  • Microsoft InfoPath 2010

    InfoPath 2010 Public Beta is Here!


    InfoPath 2010 LogoThe InfoPath team is excited to announce the release of the Office 2010 and SharePoint Server 2010 public betas! For the 1st time members of the public can download InfoPath 2010. Download it now from!

    Here are just some of the highlights in this new release. (For more details, see our earlier What's New in InfoPath 2010 post).

    Quick and Easy Form Design

    • Designing good looking forms has been made easier with our new page layout templates, layout tables, and themes.
    • With our new out-of-the-box rules and improved rules management UI, you can easily add rules to validate data, format your form, or perform other actions with just a couple of clicks, and without any code. 
    • Our new “quick” publish functionality allows you to publish forms in a single click (no more clicking through the Publishing Wizard every time you want to make an update to your forms!)
    • New Controls include the picture button, signature line control and person/group picker which is now available out-of-the-box in the controls gallery.

    SharePoint Integration
    Over the past 3 years of product development, we’ve made huge investments in integration with the SharePoint platform to make it much easier to build rich forms-based applications on top of SharePoint Server 2010.

    • Using InfoPath, you can now extend and enhance the forms used for creating, editing and viewing items in a SharePoint list.
    • With the new InfoPath Form Web Part, you can host your forms on portal pages without writing a single line of code. 
    • With SharePoint sandboxed solutions, forms with code can be published directly to SharePoint libraries without requiring administratror approval.
    • Richer browser forms:Bulleted, numbered, and plain lists, multiple selection list boxes, Combo boxes, Choice group and sections, and Filtering functionality are now supported in browser forms.
    • InfoPath Forms Services Administration and Management: We have invested in many improvements to make it easier to manage InfoPath Forms Services as a component of Microsoft SharePoint Server 2010. These include Powershell commandlets to automate tasks and SharePoint Maintenance Manager Rules to monitor the health of your server.

    New iconIntroduced since the technical preview, InfoPath now supports connecting to REST Web Services.

    Go download the beta now and send us your feedback using Send-a-Smile.


    The InfoPath Team

  • Microsoft InfoPath 2010

    New Office and SharePoint 2010 Developer Workshop available on Channel 9


    Channel9 Training Banner 

    This week, Channel 9 launched two new training courses for SharePoint 2010 and Office 2010 created by developers for developers. You’ll find extensive instructor recordings from top MVPs on how to develop against both SharePoint and office 2010.

     InfoPath is featured in:

    • Office 2010 Developer Roadmap - Office 2010 Development Tools - This video provides an introduction to building solutions for Office and SharePoint 2010 using Visual Studio 2010, SharePoint Designer 2010, InfoPath 2010, and Access 2010.
    • InfoPath 2010 and Forms Services - This unit which contains 4 videos covers development of custom SharePoint List Forms and workflows, publishing InfoPath Forms and connecting external data to InfoPath Forms.
      • What is InfoPath 2010? - This video introduces the capabilities of InfoPath, the form design experience, InfoPath Forms Services and the InfoPath Form Web Part
      • List Forms using InfoPath 2010 - This video covers how to develop a no-code, custom InfoPath form for a SharePoint List, publish the InfoPath form and then connect the InfoPath form to another List as an additional data source.
      • Working Offline with InfoPath 2010 - This video discusses offline support for InfoPath 2010 with SharePoint Workspace 2010 and the online/offline synchronization process.
      • InfoPath 2010 and Visual Studio - Developers can enhance InfoPath 2010 forms with Code Behind using Visual Studio Tools for Applications. This customization can be done in either C# or VB. This video also explains how SharePoint isolates custom code in its Sandbox environment.


  • Microsoft InfoPath 2010

    SPC Recap: Create Form Driven Mashups with the InfoPath Form Web Part


    The recent SharePoint Conference ended with a bang as Nick Dallett showed participants how they could create rich enterprise mashups by using InfoPath to create dynamic web parts without writing code.

    Nick showed off the new InfoPath form web part and demonstrated how easy it is for business users to use the web part to create composite applications together with other web parts that ship out of the box in SharePoint 2010, as well as custom web parts created by developers.

    Nick started by defining what an enterprise mashup is, pointing out three key points:
    - They are created by *business users*, not IT
    - They feature one or more sources of enterprise and public data
    - They provide visualizations of that data which helps users make better, faster, and more efficient decisions.

    He then went on to present 9 different scenarios where InfoPath was used as part of an enterprise mashup.  Each mashup illustrated a slightly different angle of the two design patterns that underlie all of the examples:

    1. The Connection-oriented design pattern, where web parts communicate using part-to-part connections, and
    2. The List-oriented design pattern, where web parts communicate by virtue of the fact that they are connected to one or more related lists

    1. Channel Analyzer (IDV Visual Fusion)
    (Design pattern 2 – list-oriented)

    Litware Channel Analyzer Application 

    IDV Solutions Logo

    Scott Caulk from IDV solutions ( gave a brief demonstration of an application built on their Visual Fusion product.  Visual Fusion is a rich Silverlight-based web part which allows users to aggregate multiple sources of data from the enterprise or the web, and visualize it in Bing maps.  Scott showed how a marketing manager for Litware books can use sales data plotted on the map to determine where a new promotional event may have the most impact.  The manager then clicks a button to fill out an InfoPath form to schedule a new marketing event.  Once submitted, data about all marketing events that have been scheduled is displayed on the map alongside the sales data.

    2. Customers and orders
    (Design pattern 1 – connection-oriented)

    Customers and Related Orders 

    Nick had some fun with the next two demos, which center around Contoso Office Supplies, where Nick moonlights as a salesman (wink wink).  After showing us the custom InfoPath form that he uses to display data from his customer list, Nick’s cell phone rang on stage, and after a brief moment of confusion (is he really going to answer a call in the middle of a presentation??), Nick let us know that the call was from Karie, the office manager over at Fabrikam.  It was all part of the show!   Karie wanted to know what pending orders she had so that she could put together the order for this week.  Nick showed how he could quickly pull related orders information into the display form’s web part page with just a few clicks, and was able to give Karie the information she needed.  Now that the web part page was modified, clicking on any customer in the list brought up not only their company information, but their pending orders as well.

    Key concept:   pull in related data using the “insert related list” action.

    3. New Order form
    (design pattern 1 – connection-oriented)

    New Order Form 

    Once off the phone, Nick put together a page from scratch displaying his customer list, with a list of orders for the currently selected customer, and an order form that was prepopulated with the customer information.  He explained the two connections that allowed him to filter the orders list based on the ID of the selected customer, and to tell the form to populate itself with customer data using a filter on a data connection to the customers list.  (NOTE: filtering and parameterized sharepoint list queries are both now supported in browser forms for SharePoint 2010!).

    Key concept: filter a data connection based on an incoming connection parameter.

    4. Customers master-detail
    (design pattern 1 – connection-oriented)

    Customers List - Master Detail 

    Nick pointed out that the simplest web part mashup to build is a master-detail scenario for a list with a custom InfoPath form.  He threw a list view onto a web part page, added an InfoPath form web part, and simply set up a connection using the “Get Form From” action to specify both the form and the connection to the list in one go.  Now, selecting a customer in the list displays the form for that customer alongside the list, allowing for quick access to data across multiple customers.

    Key Concept: build master-detail pages using the “Get Form From” connection action.

    5. Office Dogfood Voting
    (design pattern 2 – list-oriented)

    Office Build Voting Form 

    This mashup was an alternate implementation of a solution used at Microsoft to track the quality of Office builds.  As people install new builds and use them in their daily work, they can submit votes on whether the build is a good one (thumbs up) or a turkey (thumbs down), with some details.  The mashup page shows a list of builds, with aggregated information about votes cast about that build, and calculated columns which determine a rating for that build based on the number of yea or nay votes.  Nick demonstrated how the form works by submitting the vote to the underlying Votes list and then displaying a “Thank you” view to the user.  He then showed the workflow that increments the “for” and “against” counters for a build based on the submitted vote.

    Key concept: use data in a list to drive workflow and influence the display of other web parts.

    6. Microsoft Helpdesk
    (design pattern 1 – connection-oriented)

    Help Desk Form

    Next, Nick showed a page with two InfoPath forms and a list.  The Helpdesk form is an updated version of the form demonstrated in many of our InfoPath 2007 conference presentations.  It’s a rich form which shows a dynamically determined set of fields and values based on a problem category and problem area chosen by the user in a set of cascading dropdowns.  Based on the chosen category, the form sends a filter parameter, using the new Send Data to Web Part rule action, to filter a list of known solutions related to the problem category.

    A second InfoPath form in the page shows information about the logged-in user.  This display-only web part uses a query against the userprofile web service in SharePoint to bring in information from the User Profile Store.

    Key Concepts:  filtering dropdowns in the browser, using the Send Data To Web Part rule action, creating display-only web parts using InfoPath.

    7. Loan calculator
    (design pattern 1 – connection-oriented)

    Loan Calculator

    This demo showed how to use InfoPath to create a rich form that drives complex calculations in an Excel workbook hosted in Excel Services.  Nick used the Loan Calculator from Office Online, and a simple custom InfoPath form, put them both in a web part page, and then used SharePoint Designer to set up a multiple filter value connection between the form and the workbook.  The form adds default values, data validation, and visual pizzazz to the powerful calculation engine of Excel to create a compelling composite with no code.

    Key concepts:  connecting InfoPath forms with Excel, using SharePoint Designer to specify multi-valued connections.

    8. Insurance claims processing
    (design patterns 1 and 2 – list AND connection oriented)

     Insurance Claims Portal

    Nick showed a 4 part mashup centered around an insurance claims manager looking at claims submitted by customers in the wake of a violent storm.  Clicking on a claim in a list view shows the location of the claim in a custom web part using Bing maps, a photo of the damage in the Image Viewer web part, and an InfoPath form which allows him to assign an adjuster based on the geographic location and set a priority based on the damage photos.  The map shows all of the claims in the list (design pattern 2), but accepts a list item ID as a connection parameter, and centers the map on that pin when a list item is selected (design pattern 1).  Finally, clicking on a pin in the map displays the original form submission in a popup dialog using the showPopupDialog( ) javascript method.

    Key concepts: combine design patterns for complex scenarios, use Bing maps in custom Web parts, display InfoPath forms using showPopupDialog( ).

    9. The Microsoft Giving Campaign
    (design pattern 2 – list-oriented)

    Giving Campaign Web Site

    The final mashup of the day was built around the Microsoft Giving Campaign, which happens this time each year.  Employees are encouraged to donate to their favorite charities, and the donations are tracked to get an overall picture of employee giving.  The Give web mashup shows three web parts, including an InfoPath donation form, a chart web part showing aggregated donations by business division, and a custom Silverlight web part showing progress towards the campaign goal.  (The custom part is a project that Mike Ammerlaan from the SharePoint team demonstrated earlier in the week in his talk on creating web parts using Silverlight.).  This mashup features a similar structure to the Office Build Voting mashup shown earlier, in that there is a single list which contains all employee donations, and a second list which lists donations by business division.  Submitting a donation to the Donations list kicks off a workflow which updates the Divisions list with the new total donation amount.  The chart web part (which ships with SharePoint 2010) shows the breakdown of donations by division, and the Silverlight gauge web part shows a graphical representation of the total number of donations relative to a fixed goal.

    Key concepts: using custom Silverlight web parts, chart web part


  • Microsoft InfoPath 2010

    InfoPath 2010 Performance Highlights


    At last week's SharePoint conference in Las Vegas, Rick Severson, a test lead on the InfoPath product team presented a session called Performance Best Practices for SharePoint Forms Services 2010. This session covered best practices and performance improvements in InfoPath 2010. In this post, we will cover the highlights from this session.

    InfoPath Team Members who attended SPC:

    (From Back Row Left to Right: Daniel Witriol (Program Manager Lead), Darvish Shadravan (Technology Specialist), Rick Severson (Test Lead), Nick Dallett (Program  Manager Lead), Roberto Taboada (Program Manager), Bojana Duke (Program Manager), Peter Allenspach (Group Program Manager), Umut Alev (Development Lead))

    SPC - InfoPath Team Picture

    We had about 100 people in the room for this deep dive of InfoPath performance best practices. Rick opened the session by defining what fast forms are. He used a sample 1040EZ form to demonstrate a "lightning fast form" out of the box. In InfoPath Forms Services 2010, we've improved performance by achieving initial form load times of .8 seconds and subsequent form loads of .4 seconds. A sample passport form with 60 controls and some simple rules and data validation was used to demonstrate that requests per second (RPS) have increased. With this form, 1200 requests can be processed per second. That's a total of 2.1 million users per hour.

    Rick then moved on to cover some of the scalability highlights in this release.

    • Requests per second (RPS) have doubled. 
    • We can now scale out to 8 Web front ends for a single backend. 
    • Performance of SharePoint lists that have been customized using InfoPath is comparable to the default, out of the box SharePoint lists.
    • Forms with Sandboxed code can process 340 RPS in a 1x3 topology
    • Our new State Service allows for better scaling and faster session performance
    • We’ve ported many fixes into 2007 SP2 so you can take advantage of many of these performance gains today

    Performance improvements include -

    • Our new, enhanced rich text control which is optimized for multiple instances on a form
    • OnHover rendering of secondary data which improves rendering time
    • Performance in customized SharePoint lists ensures that you get the richness of InfoPath without sacrificing performance
    • New State Service
    • Optimized .js for Ajax behavior rendering

    InfoPath 2010 - Performance Improvements

    In the next part of the session, Rick covered some best practices for optimizing the performance of your forms. He focused on the following 4 areas - Data Connections, Controls, Data size and business logic.

    • For optimal performance, he recommended that you filter data at source rather than returning large data sets when querying data sources. 
    • InfoPath 2010 users can now take advantage of our new browser form filtering capabilities. 
    • Users should avoid running data queries on form load and instead run them on demand.
    • It's a good practice to combine data queries with other actions, such as view switches to minimize the number of postbacks.
    • To further improve performance, we recommend that you reduce form complexity, avoid out of context controls and avoid postbacks.
    • When possible, you should take advantage of first request optimized forms.  You can do this by avoiding logic in your form that has to be calculated on load.  For example, if you use a default value of DateTime.Now(), then this has to be calculated on load so the form cannot be first request optimized. 

    InfoPath 2010 Performance - Areas to tune

    The key takeaways from this session were high performance out of the box, complex solutions can be tuned easily and performance matters!

    Additional Resources for improving the performance of your InfoPath forms:
    Designing Browser enabled forms for Performance in InfoPath Forms Services

    Capacity Planning Document For IPFS

    InfoPath Forms Services 2007 Web Testing Toolkit

  • Microsoft InfoPath 2010

    InfoPath 2010 is unveiled at the SharePoint Conference


    As many of you may know, the SharePoint Conference 2009 is taking place this week in Las Vegas, Nevada and it's been a particularly exciting week for the InfoPath product team. Over the past 3 years of product development, we have made huge investments in integrating with the SharePoint platform. Finally, this week, we got the opportunity to unveil the fruits of these investments to the world, and so far, the reception has been tremendously positive! (Check out what people are saying about InfoPath 2010 on Twitter.)

    SPC is taking place at the Mandalay Bay Hotel:

    SPC 2009 - Mandalay Bay Hotel

    InfoPath Booth:

    (from left: Umut Alev - development lead, Peter Allenspach - group program manager, Rick Severson - test lead):

    SharePoint Conference - InfoPath Team Members

    InfoPath 2010 is well represented at this year's conference with a total of 5 sessions. The 1st session took place on Monday and was presented by Peter Allenspach and Bojana Duke from the InfoPath program management team.

    The InfoPath session drew big crowds:

    SPC 2009 - InfoPath Session Audience

    The session opened with an introduction to InfoPath 2010, followed by 3 feature demos which illustrated just how easy InfoPath 2010 makes it for Information Workers to create their own solutions without reliance on IT departments. Some highlights below -

    InfoPath 2010 Overview:

    InfoPath 2010 Overview

    Demo 1: Customizing a SharePoint list form

    In this demo, Peter and Bojana walked through a real Microsoft internal College Recruiting scenario. Employees use SharePoint lists to sign up for recruiting trips. Bojana wowed the audience by taking the Recruitment Trip list form and customizing it in InfoPath in under a minute!

    Peter and Bojana then went on to show how this form could be further enhanced and customized. Our new out of the box rules were used to add data validation and to conditionally show or hide sections in the form. A data connection to the Colleges list was added to pull details about the colleges into the recruiting trip sign-up form. The form layout was customized using our new pre-built layout tables and themes. They then showed how in a single click, the form could be published to SharePoint. Not only that, but they then showed how the list, including the customized form could be taken offline in SharePoint Workspace.

    Last but not least, they opened the form in Firefox showing that you can use your browser of choice to fill out your forms.

    Before Form:

    SharePoint List - Default Form

    After Form:

    SharePoint List - Customized InfoPath Form

    Offline Form in SharePoint Workspace:

    SharePoint WorkSpace - Offline Form

    Demo 2: Creating Mashups using the InfoPath Form Web Part
    The 2nd demo took the Recruiting scenario to the next level. In this demo, Bojana created a simple portal page with 2 Web Parts, the Recruiting trip list and the new InfoPath Form Web Part. In only a few clicks, she connected the 2 Web Parts. Now when she selected an item in the recruitment list, the details for that trip were displayed in an InfoPath form.

    Portal Page:

    InfoPath Form Web Part

    They concluded the 2nd demo by showing that both SharePoint solutions and InfoPath forms are truly portable and reusable. The site was saved as a template (WSP) and a new site was created from this template. The SharePoint list, portal page and InfoPath form were fully functional on this new site.

    Demo 3: Office Business Applications: Procurement scenario
    In this final demo,  Peter and Bojana showed the audience how InfoPath helps IT departments develop full Office Business Applications on the SharePoint platform. They used a procurement scenario to demo these capabilities. In this scenario, an employee submits a request to purchase a new laptop computer. The solution used an InfoPath form that connects to a vendor database, that brings in details about the goods you can purchase.

    Procurement Form:

    Procurement Form

    This type of application can be built in SharePoint Designer, using web part pages to create the user experience. The data can be stored in form libraries, SharePoint lists, and external systems using Business Connectivity Services. If InfoPath rules don’t do the job of defining the desired form behavior sandboxed or full trust code can be added to the forms. SharePoint workflows can be used to send e-mail notifications and track status. And once you’re all done, you can package your application so it can be tested and eventually deployed to the production servers.

    Procurement Portal Page:

    Procurement Portal Page 

    This first session set the stage for the remaining InfoPath sessions of the week:

    • Building Applications with InfoPath and SharePoint Designer (this session took place on Tuesday - more details to follow)
    • Performance Best Practices for Forms Applications
    • InfoPath 2010: Form Design Best Practices
    • Form-Driven Mashups using InfoPath and Forms Services 2010

    Stay tuned for more updates from Las Vegas!

  • Microsoft InfoPath 2010

    InfoPath 2010 Overview Video


    Check out the InfoPath 2010 overview video created by the InfoPath Product Marketing team on Click on the Videos tab and then click the InfoPath link.


  • Microsoft InfoPath 2010

    New Demo Video Posted: Creating Forms in InfoPath 2010


    The first in a series of feature demo videos created by the InfoPath Product team is available for your viewing pleasure on Youtube.

    In this video, Bojana Duke, a Program Manager on the InfoPath team, covers the basics of creating forms in InfoPath 2010 using some of our great new features including Page and Section Layouts, Quick Rules, Rules Manager and the Picture Button control.

    To learn more, check out the video on

  • Microsoft InfoPath 2010

    Office 2010 Technical Beta recruiting update and contest rules


    Hey folks,

     Since we posted the information about the Office 2010 technical beta a couple of weeks ago, and our "Win an XBox" contest, we've had quite a few folks sign up for the program.  Welcome to all the new folks in the technical beta!  There are still slots available for folks interested in InfoPath, and we'll continue to take nominations until we're full.

    Please note that the Technical Beta is different from the Technical Preview program.  Individuals and companies who are accepted into the Technical Beta sign a non-disclosure agreement and get access to both Office 2010 and SharePoint 2010. 

    The InfoPath 2010 Technical Beta Solution Contest is open only to members of the Technical Beta. In order for you to come into the program by being sponsored by the InfoPath team, you must indicate on your nomination form that you are primarily interested in InfoPath.  Also, you must include a valid e-mail address so that we can contact you to invite you into the program.

    Here are the official eligibility rules for the contest:




    This is a skill-based Contest.  The object of this Contest is to create a video demo of an application built by the entrant using Microsoft InfoPath 2010 and Microsoft SharePoint Server 2010.  For purposes of this Contest, each video demo you create and submit in the Contest will be called an “entry.”  All eligible entries received will be judged using the criteria described below to determine the winners of the prizes described below.




    This Contest starts at 12:01 a.m. Pacific Time (PT) on 8/1/2009, and ends at 11:59 p.m. PT on 10/15/2009 (“Entry Period”).




    You are eligible to enter this Contest if you meet the following requirements at time of entry:


    ·         You are actively enrolled in the Office 2010 Technical Beta  program with a valid program ID and are a legal resident of the 50 United States and District of Columbia, or Canada; and

    o   If you are 18 of age or older, but are considered a minor in your place of residence, you should ask your parent’s or legal guardian’s permission prior to submitting an entry into this Contest; and

    • You are NOT an employee of Microsoft Corporation or an employee of a Microsoft subsidiary; and
    • You are NOT involved in any part of the administration and execution of this Contest; and

    ·         You are NOT an immediate family (parent, sibling, spouse, child) or household member of a Microsoft employee, an employee of a Microsoft subsidiary, or a person involved in any part of the administration and execution of this Contest.

    This Contest is void outside the geographic area described above and wherever else prohibited by law.



    The full rules of the competition, including instructions on how to submit your video demo, are posted on the official forums that are accessible to members of the Technical Beta.


    The link to nominate yourself for the program is here:


    I'm really looking forward to seeing the great solutions you come up with using the great new features in InfoPath 2010 and SharePoint 2010.  Thanks for your continued support!


    -Nick Dallett

    Lead Program Manager, Microsoft InfoPath

  • Microsoft InfoPath 2010

    InfoPath 2010 feature videos


    Check out some of the new InfoPath 2010 features in action in the following videos on youtube:

    InfoPath 2010 Richer Browser Forms

    InfoPath 2010 Picture Button

    InfoPath 2010 Oneclick Publishing

  • Microsoft InfoPath 2010

    What's New in InfoPath 2010?


    Here's a quick overview of some of the great new features in InfoPath 2010. Stay tuned for upcoming posts with more details!

    Microsoft InfoPath 2010 makes it easier than ever to design electronic forms. InfoPath now includes the Office Fluent UI and allows the creation of powerful, interactive forms, without having to write any code. With a few clicks, Office users can customize SharePoint list forms, add custom layouts and rules to validate the data, and take them offline in SharePoint Workspace.

    IT professionals can create custom forms for document workflows and Office Business Applications that include managed code, digital signatures and that connect to line of business data.

    In InfoPath 2010, we’ve made some big investments to make it much easier to build rich forms-based applications on top of the SharePoint Server 2010 platform.

    Quickly Design Forms with Easy-to-Use Tools
    New features to help you quickly and easily create forms include our new Fluent UI, pre-built layout sections, out-of-the-box rules, improved rules management, and varied styles. 

    The New tab in the Designer Backstage presents you with the available form templates that you can choose from. Most templates start you off with a default layout table.

    InfoPath 2010 Designer New Tab

    Stay tuned for more details on our new and improved form design features!

    Layout your Forms Using Pre-built Page and Section Layouts
    Laying out your form and making it look more attractive is now easier than ever. Insert one of our pre-built page layouts to give your form structure. Then, insert some section layouts into the page layout to start building your form.

    Page and Section Layouts in InfoPath Designer:

    InfoPath 2010 Designer Layouts

    New and Improved Controls
    We’ve added some new controls and narrowed the feature gap between client and browser forms, ensuring a more consistent form filling experience for all our users.

    New controls in InfoPath 2010 include:

    • Picture buttons – Instead of the default gray button, use any image as a button in your form.
    • Hyperlink capabilities –Allow users to insert their own hyperlinks when filling out forms.
    • Date and time picker – Allow users to insert dates and times in their forms
    • Person/Group pickers – Updated! This is now a first class control and is included by default in the Controls gallery.
    • Signature Line (Editor Only) – Allow users to digitally sign a  form

    Controls and functionality that are now supported in browser forms include:  

    • Bulleted, numbered, and plain lists, multiple selection list boxes, Combo boxes, Choice group and sections, and Filtering functionality.

    Add Rules to your Forms
    With our new out-of-the-box rules (or quick rules) and improved rules management UI, you can easily add rules to validate data, format your form, or perform other actions with just a couple of clicks, and without any code.

    Quick Rules in InfoPath Designer:

    InfoPath 2010 Designer Quick Rules

    Publish Forms Quickly
    Our new “quick” publish functionality allows you to publish forms in a single click (no more clicking through the Publishing Wizard every time you want to make an update to your forms!)

    Create Forms for SharePoint Lists
    Using InfoPath, you can now extend and enhance the forms used for creating, editing and viewing items in a SharePoint list. In a browser, simply navigate to a SharePoint list, and on the SharePoint Ribbon under List Tools, choose the Customize Form option. This will automatically generate a form which looks very similar to the default out-of-the-box SharePoint list form.

    You can then customize and enhance this form by modifying the layout, creating additional views or pages, and adding rules to validate your data, show or hide sections of the form or set a fields value (to name just a few of the options).

    Example of Customized SharePoint List Form:

     Customized SharePoint List Form
    Stay tuned for more details on SharePoint List Customization!

    We recommend using a form associated with a SharePoint list when possible. This provides the most straightforward design and form management experience. However, there are more complex scenarios where using a form associated with a form library is preferred e.g. if your form has a complex schema or if you need to add code to your form. 

    Create SharePoint Applications
    With InfoPath 2010, SharePoint Server 2010, and SharePoint Designer 2010, you can easily create powerful team, departmental or enterprise applications on top of SharePoint Server.

    • Form-based applications: InfoPath forms can be integrated with components such as workflow, reporting, and custom Web pages to create rich form-based applications.  
    • Document Workflows: InfoPath can be used to design custom workflow initiation and task forms that drive document management processes.
    • Business Connectivity Services: Integrating with BCS, it is straightforward to design InfoPath forms that create, read, update, and delete business data from a back-end system. 

    Stay tuned for more details on creating SharePoint applications!

    Create Mashups using the InfoPath Form Web Part
    Now, without writing a single line of code, you can host your InfoPath browser forms in Web pages by simply adding the InfoPath Form Web Part to a Web Part page. You can also connect it to other Web Parts on the page to send or receive data.

    Stay tuned for more details on the InfoPath Form Web Part!

    Build Forms with Code
    Using Visual Studio Tools for Applications, you can add managed code to your forms.

    Stay tuned for more details on programming with InfoPath! 

    InfoPath Editor
    The InfoPath 2010 Editor Fluent user interface provides a much improved, simpler user experience for filling out forms.

    Form opened in InfoPath 2010 Editor:

    InfoPath 2010 Filler
    SharePoint Workspace
    InfoPath 2010 is the forms technology used by SharePoint Workspace 2010 for creating and filling out forms.

    InfoPath Forms Services Administration and Management
    We have invested in many improvements to make it easier to manage your InfoPath Forms Services as a component of Microsoft SharePoint Server 2010.


    We hope you enjoy using InfoPath 2010 and look forward to getting your feedback!

    The InfoPath Team


  • Microsoft InfoPath 2010

    Install the Office 2010 Technical Preview and win an Xbox 360 Elite!


    We on the InfoPath team are delighted to announce the release of Microsoft InfoPath 2010 (Technical Preview). We’re really excited to share all of our great new features with you!

    (Click the thumbnails for higher-resolution images.)

    InfoPath 2010

    InfoPath Desiger 2010


    • Use InfoPath to customize SharePoint list forms
    • Design forms more quickly and easily with page and section layouts, themes, and Fluent user interface.
    • Add smarts to your forms with pre-built rules
    • Publish your forms with one-click

    Where do I sign up?
    The Office 2010 Technical Preview is a limited-availability release.  To sign up to be considered for the Office 2010 Technical Preview program:

    How do I win the Xbox? 

    • Build a real-world end to end application using InfoPath 2010 and Microsoft SharePoint Server 2010.
    • Download the Community Clips Recorder from 
    • Record a walkthrough of your solution, showing us how you used InfoPath forms and other Office technologies (5 minutes maximum)
    • Submit the finished video to us

    Contest is limited to eligible members of the InfoPath 2010 Technical Preview program referenced above, and additional limitations may apply.  All submissions will be reviewed by the InfoPath team, and prizes will be awarded in several categories, including best overall solution, best video, and best bug.  Contest details will be posted on the technical preview site at

    We will post more details on our new features in the coming weeks. Stay tuned!

  • Microsoft InfoPath 2010

    New book on SharePoint content types


    Have you ever wanted to do more with content types in SharePoint, but weren't quite sure how?  There's a new book by David Gerhardt and Kevin Martin which goes deep on the subject, including a chapter on creating Document Information Panels using InfoPath.

    Check it out!

  • Microsoft InfoPath 2010

    Estimate performance and capacity requirements for InfoPath Forms Services environments


    A new document went live today on Technet around capacity planning for IPFS.  Have a look and let us know what you think:




  • Microsoft InfoPath 2010

    Do you have what it takes to define the future of InfoPath?


    Program Manager Wanted
    The InfoPath clan is looking for a new member who’s skilled in the dark arts of user experience design. We are looking for someone who can help vanquish the evil of complex interfaces that tax a helpless populace. We are searching far and wide for a PM who can wield UI heavy feature areas and who can fiercely impart their passion for user experience excellence upon our kin. For those who dare to cross us, know that we are a young and boisterous clan, we move quickly to keep our territory growing and our ranks fun.

    The great and triumphant history of the InfoPath clan
    Once upon a time those of us seeking the path to information settled upon the land of electronic forms. It was the year MMIII, a time immediately following the failed invasion of the great bubble. Ours was a chaotic and grim landscape dominated by old and decrepit offerings. In response, our people focused on creating a new generation of e-form, one that was fully ‘e’ from its inception, one without a history tied to the ancient convoluted ways of papyrus. Our people created an e-form that fully embraced the interoperability of the ‘e’ world, being compliant with the scriptures of XML and sending/receiving information using the silky services that permeate the great Web of truth. We called ourselves “InfoPath”, forever symbolizing our mission as the righteous seeking the path to information. Today our craftsmen are forging the next incarnation of e-forms. Working under the protection of the great rulers of the Office Kingdom, we fashion the Microsoft Office InfoPath product which provides both an e-form designer and an e-form filler. Moreover, our clan provides components that are used throughout the isle of Office, finding their way into offerings including Word, Excel, PowerPoint, Outlook, Groove, and SharePoint Designer. Those who would evade the clients of the Office Kingdom, utilize our Web-based technology to fill out InfoPath forms on Web sites hosted within the famed and cavernous Microsoft Office SharePoint Server. With the upcoming renaissance number XIV of the Office Kingdom a great many changes have been set afoot to satisfy humans and giants alike. 

    The Oracles
    Our oracles tell us that in future times our craftsman will continue lowering the bar to entry for e-form design. We will move away from InfoPath’s early days as a tool wieldable only by developers and the strongest of Office users. We will target a broad base of Office citizenry including those who like the creature comforts available in the Babbage-like sheets of Excel and the Morton-like sites of SharePoint. We will integrate more tightly with those in the Office Kingdom, mixing ourselves completely into the bricks that bond to form the citadels of Office client and Office server. We will seek out new life and new civilizations… we will find the mythical creature known only as ‘Silverlight’. Its glow is rumored to be able to improve the visual look and feel of forms. It is said to be able to make them fly… or at least float.

    Dost thou have what it takes?
    -- I am skilled in user experience design and have proven experience working in the design field. Please bring or send us a portfolio of your work. 
    -- I like enterprise software, it’s not all about games and music for me…
    -- I have passion to spare, I was born to drive the value of a great user experience across a team.
    -- I like working in a team environment, my peers describe me as a “people person”.
    -- I have an educational background that would lead me to succeed at Microsoft in the Program Management role such as a BS or MS degree in Computer Science or a related field, or a minimum of 3 years industry experience.

    (Note: Despite the flavor of this job posting, no experience in Renaissance Fairs, Dungeons and Dragons, or Old British Reenactments is expected or required. You don’t even need to have enjoyed Harry Potter. Just knock our socks off and you're in!)

  • Microsoft InfoPath 2010

    Are you ready to join the InfoPath dev or test team?


    Are you ready to take the next step, and make the move from writing tools that use InfoPath, to writing InfoPath itself?  We currently have open positions in Development, and Test. 

    To search for positions on the InfoPath team, have a look at these positions on the Microsoft careers site: 

    Software Development Engineer

    InfoPath is an integral part of Microsoft Office and Microsoft Office SharePoint Server (one of the fastest growing businesses at Microsoft). We are a team that is tasked with delivering some incredibly powerful scenarios that will greatly enhance the Microsoft Office SharePoint Server brand. Do you want to be part of a team that will deliver to our customers some incredibly rich forms and views using the latest AJAX/web-service technology? If the answer to these questions is yes and you have the qualifications noted below, we want to talk to you.


    You must have a proven track record of shipping software through at least one product cycle while dealing with challenges such as cross-team dependencies and a constantly evolving ecosystem. You must also be able to extend your impact by working with other team members to instill strong design principles.

    You must also have solid fundamental computer science skills and have a passion for cutting-edge software development. Proficiency in C++, C# and JavaScript are required. Experience with AJAX, Dynamic HTML, and web services are big pluses. A Good understanding of basic algorithms and data structures, effective communication and cross-group skills are essential. A BS/MS in Computer Science or Engineering, or equivalent, and 1 to 5 years of software development experience are required.

     Software Development Engineer in Test

    Are you passionate about XML and related technologies? Do you want to help millions of users migrate from paper forms to electronic forms?
    Started in Office 2003, InfoPath provided the ability to easily design and fill out electronic forms. InfoPath enables information workers to hook up their forms to various XML data providers like databases, SharePoint Team Services, and web services. In our latest version, we expanded our product to integrate with other Office 2007 applications, such as Word, Excel, and Outlook. This is just the start for InfoPath and you can be part of the force to change how people fill out forms in the future!
    In the next release of InfoPath, we are committed to improve the user experience. We will add many new feature sets and move to a new rendering framework. We’re looking for a strong SDET who is passionate about shipping highest quality product and has shipping experience in at least 1 complete product cycle. Ideal candidate would be technical, self-motivated, and customer focused. You can work directly with developers and program managers under minimal supervision. You have excellent communication skills and able to work with test counterparts across Office. The job involves owning and testing features end-to-end, providing feedbacks to product design, creating test design spec and test cases, writing automation, analyzing and troubleshooting manual and automated test cases.
    The position requires a Bachelors degree in Computer Science or equivalent experience. Familiarity with XML, .NET technologies, C#, C/C++, VBscript/Jscript is a plus.

  • Microsoft InfoPath 2010

    Consuming Excel Data using InfoPath Database Data Connections


    InfoPath data connections can be one of the most powerful features of the product.  However, sometimes the out-of-box support for various data sources just doesn't seem to cut it when you get out into the field.  How in the world can I get data from an Excel spreadsheet  into my InfoPath form?  A typical response might include externally automating Excel via COM or the managed PIA to create InfoPath forms.  Or you might try using the Excel 2003 XML spreadsheet file format with the InfoPath XML data connection.  While both solutions are feasible, they can be a bit clunky to manage multiple files generated from your spreadsheet…
    Here is your question answered!  Access 2007 provides support for linked tables, virtual tables that pull data from a data source external to an Access database.  Since InfoPath has a built-in database data connection that can query data directly from an Access database, Access 2007 can effectively act as a router for data sources that aren't directly supported by InfoPath.  In this post, we'll step through setting up an InfoPath database data connection that queries data from an Excel spreadsheet.
    Prepare your Excel spreadsheet
    Once you've added all the necessary data to your Excel spreadsheet, save the Excel workbook to a shared network location that will be accessible to all users filling out your InfoPath form.
    Create the Access database to link the Excel data
    Launch Access 2007 and create a new blank database.  When you create a blank database, a default table will be created.  Go ahead and delete the table (just closing the query view should remove the table.)
    Switch to the "External Data" tab in the Ribbon


    Click the "Excel" icon in the "Import" chunk to launch the "Get External Data - Excel Spreadsheet" wizard.
    Browse to the Excel workbook that you saved in the "Prepare your Excel spreadsheet" section, above.
    Select "Link to the data source by creating a linked table" and then click "OK".


    Choose the Sheet or Named Range that you want to import, then click "Next >". If the first row of the spreadsheet contains column headers, check the "First Row Contains Column Headings", then click "Next >".

    Type a name for the linked table (I'll call it "Spreadsheet" for this post), then click "Finish".
    Click "OK" when Access tells you it's done linking the table.  When the dialogs close, you'll see the linked table listed in the "All Tables" task pane


    Save the Access database to the same directory where the Excel file was saved, then close Access.
    Design the InfoPath Form Template to Query the Linked Table
    Design an InfoPath Form Template based on a "Database" (you could also add the data connection as a secondary database data connection in an existing form template).


    Once you've clicked "OK", the "Data Connection Wizard" will open.  Click "Select Database…" to open the "Select Data Source" file browser dialog.

    Click "New Source…"

    NOTE: At this point, it's tempting to just browse to the Access database as you normally would.  However, the default provider used in that case does not support linked tables, so InfoPath will see no tables in the database.  In order to select the appropriate provider, you have to click "New Source…"


    Select "ODBC DSN", then click "Next >".
    Select "MS Access database", then click "Next >".

    Browse to the Access database that you created in the "Create the Access database to link the Excel data", above, then click "OK".

    NOTE:  This browse dialog can be a bit confusing.  If you get mixed up by the unusual browsing experience, you can just type or paste the full path to the database in the "Database Name" field (boxed in green in the screenshot below).


    Select the name of the linked table, then click "Next >"
    Finish the data connection wizard as you would for any other database data connection.
    At this point, you're good to go.  The data connection to your Excel data will behave the same as a query-only Access database data connection.

    - Forrest Dillaway, InfoPath Test


  • Microsoft InfoPath 2010

    New InfoPath articles on Office Online


    The following new article and video demos are now available on the InfoPath Home Page on Microsoft Office Online:


    Get started: Create a meeting note system with InfoPath and SharePoint-shows you how to use a sample form template included with InfoPath and a SharePoint document library to create a meeting note system.


    Demo: Store InfoPath forms in a document library on a SharePoint site-watch how you can publish a sample form template to a new document library.


    Demo: Populate a drop-down list box from a SharePoint list—watch how you can put that SharePoint list into a list box control on an InfoPath form template.


    At the end of each article, you can let me know if you like or hate these articles by answering the question, Was this information helpful?, and then entering your comments and suggestions in the box. I read your comments every month and either write new or modify existing articles based on your comments.


    Thank you for using InfoPath!


    Arsenio Locsin

    InfoPath Technical Writer

  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 6)


    Part 6 – Addendum: Links to related performance resources

    Welcome to the sixth article in our series about designing InfoPath browser-enabled forms for better performance and scalability. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. We also described some of the issues that affect form-rendering performance in the browser and suggested using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer. Finally, we listed some useful performance monitoring counters available in PerfMon.

    In this addendum, we list a variety of links to additional resources you might want investigate if you are interested learning more about designing forms with InfoPath 2007. In keeping with our theme, the emphasis is on performance, but you will also find other related resources that you can use to broaden your understanding of the online forms environment. Since InfoPath is built on SharePoint technologies, the following resources provide information not only on InfoPath Forms Services and browser-enabled forms, but also SharePoint, ASP.NET, and SQL Server. In addition, we’ve included some general resources on monitoring and testing, and thrown in a few good blogs as well.

    Hope you’ve found this series helpful in demystifying InfoPath browser-enabled forms performance. Be sure to let the InfoPath team know if you have comments or questions about your own forms requirements by adding comments here or on the InfoPath newsgroup listed below!


    Brad Valantine
    Technical Writer


    Improving the Performance of InfoPath 2007 Forms
    A whitepaper about performance and the InfoPath rich client. Because of differences between the client and browser-enabled forms, not everything applies to Forms Services and browser forms, but a must read nonetheless.

    InfoPath Forms Services best practices

    Microsoft Office Forms Server TechNet TechCenter

    InfoPath Forms Services roadmap

    InfoPath 2007 features that are unavailable in InfoPath Forms Services

    Forms Server 2007 Home Page

    InfoPath 2007 Home Page

    Planning and architecture for Office Forms Server 2007

    Plan InfoPath Forms Services

    Office Developer Center: InfoPath 2007 Resource Center

    InfoPath Forms Services Architecture

    Form Development and Deployment Lifecycle

    Creating InfoPath Form Templates That Work With Forms Services

    Support: Microsoft Help and Support: Forms Server 2007 Solution Center


    Plan for performance and capacity (Office SharePoint Server)

    Plan for performance and capacity (Windows SharePoint Services)

    White paper: Intel Performance Testing of Windows SharePoint Services (WP)

    How to Optimize a SharePoint Server 2007 Web Content Management Site for Performance

    White paper: Planning and Monitoring SQL Server Storage for Windows SharePoint Services: Performance Recommendations and Best Practices


    ASP.NET Performance

    ASP.NET Session State Overview

    Developing High-Performance ASP.NET Applications

    Monitoring ASP.NET Application Performance

    SQL Server

    Performance (Database Engine)

    Monitoring (Database Engine)

    Monitoring and Testing

    Life-Cycle Performance Testing for Eliminating Last-Minute Surprises

    Server Performance and Scalability Killers

    Performance Counters in the .NET Framework


    Designing Forms for Microsoft Office InfoPath and Forms Services 2007 (Microsoft .NET Development Series)
    By Scott Roberts and Hagen Green
    Publisher: Addison-Wesley (c. 2007)
    ISBN 0321410599

    A couple of great online books from the folks in Patterns and Practices:
    Improving .NET Application Performance and Scalability

    Performance Testing Guidance for Web Applications


    Blogs and Newsgroups

    Pashman's InfoPath Goldmine: Tips and Tricks for Tuning Forms Services Performance

    Performance Research, Part 1: What the 80/20 Rule Tells Us about Reducing HTTP Requests
    The first article in a series about research done by Yahoo into web page performance optimization.

    Agile Testing: Performance vs. load vs. stress testing

    Ben Curry: Using Performance Monitor (perfmon.exe) to Monitor SharePoint Server 2007

    Ben Curry: SharePoint Server 2007 Performance Counters

    Thom Robbins .NET Weblog: InfoPath Tips and Tricks

    Joel Oleson's Blog - SharePoint Land:
    Performance & Scale

    Good List of Performance Counters

    S.Y.M. Wong-A-Ton: Enterprise Solutions

    Paul Vick - Panopticon Central: The Ten Rules of Performance

    Technorati - infopath Blogs, Photos, Videos and more on Technorati

    Discussions in Infopath General Questions
    Use this newsgroup to communicate with the InfoPath community.

    MSDN Forums: SharePoint - InfoPath Forms Services
    This forum is another place you can ask questions about Forms Services.


  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 5)


    Part 5 – Addendum: Counters for monitoring form server performance

    Welcome to the fifth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. We also described some of the issues that affect form-rendering performance in the browser and suggested using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.

    In this addendum article, we list some useful performance counters you can use in the Windows Performance Monitor (PerfMon) to monitor the behavior of your form server system. Using a combination of general system counters and InfoPath-specific counters to monitor the performance of your servers can help you troubleshoot issues and quantify the performance effects of changes you make to the design of your InfoPath form templates.

    System counters for monitoring your form server system

    There are two key places where performance bottlenecks can occur in your form server system, on your Web front end (WFE) servers and on your SQL Server back end. The bottlenecks that occur on the front end are normally CPU bound, while the bottlenecks at the SQL Server back end are normally either disk bound or CPU bound.

    You can use the following system counters in PerfMon to check the performance of your WFE and SQL Server systems under various load conditions. Use these counters to determine whether your servers are performing at acceptable levels and to help identify any bottlenecks.

    Counters for monitoring a WFE server system

    • CPU:
      Processor\% Processor Time\_Total
      Indicates the total CPU load on the server.

    • ASP.NET:
      ASP.NET \Requests Queued
      A linear increase of this counter with user load can indicate that an application is experiencing a bottleneck, either at the front end or the back end. Correlate with other ASP.NET counters, SQL counters, and WFE CPU counter to understand which part of the system is getting bottlenecked.

      ASP.NET\Requests Execution Time
      Use this counter to find which type of form template takes more time to execute in the server. In general, forms with managed code require more execution time than forms that don’t. If this counter and WFE CPU counter are high while the SQL transactions/second counter and SQL CPU counter are low, then the bottleneck is at the WFE side. This may be an indication that the form complexity is high or that the form has a lot of managed code.

    • Memory:
      No. of current logical threads
      If the count is increasing, then the thread stacks are leaking.

      Private bytes and No. of bytes in all heaps
      If the count of private bytes is increasing while the number of bytes in all heap counter is stable, then the unmanaged memory is leaking.
      If the count of private bytes is increasing and the number of bytes in all heap counter is also increasing, then the managed heap is building up.

    Counters for monitoring a SQL Server system

    • CPU:
      Processor\% Processor Time\_Total
      Values above 25% indicate a possible bottleneck. Values above 80% signify extreme CPU-bound SQL operations. A linear increase in CPU with user load indicates that SQL will become a bottleneck.

    • Disk:
      Counter should be less than 1.5 or 2 times the number of RAID disks. Correlate with % Disk time counter and Current Disk Queue counter to determine whether the disk is a bottleneck. Decrease your test load to see if the values go down.

      SQLServer:Locks\Number of Deadlocks/sec\_Total
      Value should be zero.

    • Memory:
      Non-zero value for a sustained period of time indicates that the system is experiencing a high memory load. SQL Server works best when the operating system does not reallocate its memory.

    Counters provided by the InfoPath Forms Services performance object

    InfoPath Forms Services installs a set of counters that can be viewed in PerfMon. There four types of counters provided by the InfoPath Forms Services performance object: Transaction, Session, Data Connection, and Template/Document.

    • Transaction counters represent all communication between the browser and the server. You can use the transaction counters to monitor how long postbacks are taking to complete and as a gauge for how expensive they are for the server to process.

      Avg. Transaction Duration
      The average time to complete a transaction in form-filling sessions.

      Transactions Started Rate
      The rate at which transactions started in form-filling sessions.

      Transactions Completed Rate
      The rate at which transactions completed in form-filling sessions.

    • Session counters provide duration and rate information for user form-filling sessions. If there are too many active sessions for the server to handle, you will see excessive average durations that indicate a server bottleneck.

      Avg. Session Duration
      The average time to complete a form-filling session, summed up over all transactions in the form-filling session.

      Sessions Started Rate
      The rate at which form-filling sessions started.

      Sessions Completed Rate
      The rate at which form-filling sessions completed.

    • Data Connection counters show the duration and rate of both data connection submit and query activities, along with failures. This will give you an indication of back end performance and how long data connections are taking to complete.

      Avg. Data Connection Submit Duration
      The average time to complete a data connection submit in form-filling sessions.

      Data Connection Submit Started Rate
      The rate at which data connection submits started in form-filling sessions.

      Data Connection Submit Completed Rate
      The rate at which data connection submits completed in form-filling sessions.

      Data Connection Submit Failure Rate
      The rate of failures for data connection submits in form-filling sessions.

      Avg. Data Connection Query Duration
      The average time to complete a data connection query in form-filling sessions.

      Data Connection Query Started Rate
      The rate at which data connection queries started in form-filling sessions.

      Data Connection Query Completed Rate
      The rate at which data connection queries completed in form-filling sessions.

      Data Connection Query Failure Rate
      The rate of failures for data connection queries in form-filling sessions.

    • Template/Document counters give information about the number of forms and form templates that are currently in the ASP.Net cache and in memory. These can help you monitor and detect memory utilization issues on your server.

      # of Cached Form Templates
      The number of form templates that have been added to, and not yet expired out of, the ASP.NET object cache.

      # of Business Logic Assemblies in Memory
      The number of business logic assemblies currently loaded in memory. Administrator-approved form templates may contain zero, one, or more managed code assemblies.

      # of Form Templates in Memory
      The number of form template objects that are currently loaded in memory.

      # of Cached Form Templates in Memory
      The number of forms that are currently loaded in memory.

    Server system health monitoring

    The general system counters and InfoPath Forms Services counters listed above are useful for monitoring specific issues on a server, but do not provide comprehensive health monitoring for your overall form server system. For that you need to use a solution designed to watch multiple servers for issues that may cause service or performance degradation, such as Microsoft System Center Operations Manager 2007. Operations Manager uses management packs that contain predefined rules, settings, and agents to monitor a specific service or application. For SharePoint, you can download the SharePoint Monitoring Toolkit, which contains the management packs and documentation for both Windows SharePoint Services 3.0 and Microsoft Office SharePoint Server 2007. Note that System Center Operations Manager also provides the capability to customize existing rules or create your own rules.

    For more information about the SharePoint management packs for Operations Manager 2007, see the SharePoint Monitoring Toolkit Executive Overview (

    For more information about Microsoft System Center Operations Manager 2007, see the System Center Operations Manager TechCenter (


  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 4)


    Part 4 – Browser Rendering Issues

    Welcome to the fourth article in our series on optimizing the performance of InfoPath browser-enabled forms. In our previous articles we defined performance in terms of responsiveness, listed a number of conditions that cause postbacks, and looked at some of conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system. In this article we’ll examine some of the issues that affect form rendering performance in the browser. We’ll also take a quick look at using the Design Checker to monitor browser compatibility issues while designing a form template in the InfoPath Designer.

    Conditions that slow form rendering in the browser

    There a several conditions that can reduce form-rendering performance in the browser. The main effect of these conditions is that the user experiences delays and sluggishness when working with the form. The reduced performance experienced because of slow form rendering in the browser generally occurs at the following times:

    • When the form initially loads

    • When the form is updated and re-rendered after a postback response

    • When there is a change to the display of the form in the browser that does not involve a postback

    If the designer can reduce or eliminate conditions that are more expensive for the browser to render, the form will render more quickly, and feel more responsive to the user. As with other design issues we’ve examined that affect postbacks and server performance and scalability, addressing performance issues that affect browser rendering must be balanced with your unique design and business requirements.

    • Rich Text Box control

      The Rich Text Box control creates HTML elements for the content added to a rich text field. Depending on the amount of content and formatting added by the user it can end up creating a large number of HTML elements, which can impact browser performance. One issue with using a rich text field is that you cannot predict how much data a form user might add to the field. For example, a user could paste a large rich text selection into your form from just about any source. Although the Rich Text Box control for a browser-enabled form does not allow embedded images, only linked images, the content could still be quite large.

      Unfortunately, for browser-enabled forms the InfoPath Designer does not provide a way to limit the amount of data entered. Consequently, you should consider carefully how your users are likely to use any rich text fields you add to the form and limit the number of rich text fields that are visible in a view. If you need multiple rich text fields, consider using multiple views rather than putting them all on a single view. As an alternative, consider using a Multi-line Text Box control instead.

    • Nested Tables

      Rendering HTML code for tables is a relatively expensive operation for a browser. Nesting tables by inserting one table inside another, especially if they are nested several levels deep, compounds the complexity and is generally slow for a browser to render. For better rendering performance, consider using adjacent non-nested tables rather than nested tables.

    • Conditional formatting

      We looked at conditional formatting in an earlier article, touching on the interaction with postbacks to the server and how conditional formatting expressions fire each time the form is re-rendered. Since the browser must manipulate all the data, whether it is visible or not, this can be an expensive operation that makes the form display feel less responsive. While conditional formatting can be a useful design tool, there are times when the performance cost may outweigh the benefits. For example, if a form contains a large amount of data and a substantial part is hidden, the conditional formatting can slow the form display even though some of it isn’t rendered.

      In this case, designing the form with multiple views might improve the form’s display performance compared to the single view with hidden content. Although it will cause a postback each time there is a switch to another view, the user’s interaction with each of those views in the browser may feel more responsive. This is because each view has a smaller amount of data to render than the single view containing hidden data. The tradeoff you need to consider here is between the browser-side responsiveness of the form display and the server-side scalability of your form system as it processes postbacks: using conditional visibility might slow form display, but reduce the number of server requests, while using multiple views improves form display, but increases server requests and reduces scalability.

      As another example of how subtle performance tradeoffs can be, as noted in the earlier article, it is also possible to have a design where the form display is more responsive if it uses conditional formatting to hide some data. This is happens in a situation where the browser actually takes longer to render all the elements than it takes to process the conditional formatting and hide some.

      If you suspect you have a situation where conditional formatting could either help or hinder your form’s performance in the browser – or your server scalability – try alternate designs and test them to determine which design best meets your requirements.

    • Drop-Down List Box controls with many items

      Drop-Down List Box controls can generate a large amount of HTML, especially when there many items provided in the list. The amount of HTML balloons when the list control is contained in a repeating section or table. For example, if you include 50 items in a list, and the list is repeated 50 times, the underlying HTML code will grow very rapidly and slow down rendering of the form! Try to limit the number items in lists that are used in repeating elements or limit the number of repeating elements. Alternatively, you can try using conditional formatting, putting the repeating elements containing drop-down lists into a section that is hidden by default. Because they are not supported in browser-enabled forms, some of workarounds you might consider using if you are familiar with InfoPath rich-client forms, such as a Master-Detail control or one of the other list controls, are not available. About the only other alternative might be to emulate the list using a repeating table with each item on a row (and some fancy formatting). One situation to watch out for is using an external data source to provide the list items. If you need to do this, then you also need to make sure the number of items provided by the data source is limited to a reasonable number. As with any design, it is always a recommended best practice to test alternative designs for expected (and exceptional) data sizes to determine how your form designs perform.

    • Many visible controls

      Forms that have a large number of InfoPath controls visible in a view will reduce browser performance. Again, this is amplified when the controls are in repeating sections or tables. The first suggestion is to use multiple views so that each view has fewer controls to be rendered. If you use multiple views, make sure that controls are only bound once in the view in which they are used (use the Design Checker). Once again, you can also use conditional formatting to hide some of the controls, but this will typically achieve a smaller gain in browser performance compared to using multiple views. Because there are a number of important variables that determine browser rendering performance, your design alternatives should be tested in the common user environments you expect (data size, browser type, user's machine configuration) to determine acceptable number of controls and the relative performance of each design.

    • Calculations that use large data sets

      If you design a form that includes calculations and the data for the calculations is loaded from an external data source, then that data will be downloaded to the browser so that the calculation can run in the browser without a postback to the server. Normally this strategy improves overall performance by reducing postbacks. However, if the data set is large, the benefit of eliminating postbacks can be overtaken by the performance cost of handling the data in the browser. First, it is more expensive to load a large data set; second, it is expensive to run after it is loaded.

      If you find that the browser is too slow when running calculations with large data sets, you can force a postback so that the calculation runs on the server instead. In the InfoPath Designer, for the field that runs the calculation, add a button and change the postback setting to always require a postback. When the user clicks the button to run the calculation, it will postback to the server to evaluate the calculation and return the result to the browser for display. Like most performance suggestions, you need to balance performance in the browser with the performance and scalability of your form server system.

    • Reporting scenarios

      InfoPath is primarily designed to address form-filling scenarios. Although it can also be used to display data in a reporting scenario, this can have a negative impact on browser performance as the amount of data downloaded for display increases. If there is a possibility that the amount of data could be very large, then you can expect performance problems not only in the browser, but also on the server. Depending your ability to predict and limit the amount of data in a reporting form, it might be possible to maintain acceptable performance by using multiple views and read-only controls. However, if the data is too large or cannot be limited practically, you should consider an alternate reporting solution.

    • Internet Explorer 6

      If you have form users that are using Internet Explorer 6, they will experience reduced browser performance compared with other browsers due to known issues with IE6 JavaScript performance. You might consider providing a statement on your site about browser support, and if you know you have a substantial number of users running IE6, then it is a good practice to include IE6 performance testing in your development plans.

    Use the Design Checker to monitor browser compatibility issues

    The InfoPath Designer allows you to design forms that run in both the rich-client and a browser. When you are designing browser-enabled forms, and especially when you want your form to support running in both environments, you need to be careful about browser compatibility issues. As you are designing a form template in the InfoPath Designer, you can use the Design Checker task pane to monitor any browser compatibility issues detected by InfoPath, including those that affect performance.

    Among the messages displayed by the Design Checker are warnings for controls that will trigger postbacks to the server (these messages are hidden by default; to view them, select "Browser Optimization Messages" from the Options button at the bottom of the Design Checker). One or messages can appear for each control that will post back to the server when the value of the control changes.

    Sometimes the postback occurs because of a calculation, binding, or other expression on that control. Occasionally a control will post back to the server not because of a property on that control, but because that control is contained inside a section or a table where some other control forces a postback, or the control contains a section, table, or other controls inside it that cause a postback. In these cases, the warning messages indicate that you should look for another control marked as a primary cause of the postback; examining the messages for that control can help you locate, understand, and control postbacks caused by related controls.

    If having other controls bound to the same element or group are causing unwanted postbacks, consider using separate views, with the control bound once in each view.

    To resolve issues where the binding of the control requires server evaluation, or a node is listed as only available on the server, you might need to simplify your schema.

    You can change the default postback behavior for an individual control using the Postback settings options on the Browser forms tab in the Properties window for the control. There are three options available: Never, Always, and Only when necessary for correct rendering of the form (recommended). You can reduce the number of postbacks by changing the setting to Never. If you select Never, then the control will not send data to the server on change; the data will only go to the server and formatting, calculations, etc. will only run when the form user saves or submits the form, or another control in the form causes a postback to the server. For controls you want to change, you must change the postback setting option on each control individually; changing the option on a section or group control does not automatically change the value for every control inside it.

    Note that you should carefully consider the effect of changing postback behavior to ensure that the result is acceptable for your environment. Be careful about suppressing postbacks that affect the user’s form-filling experience to avoid issues where displayed data could be incorrect. You never want to sacrifice data integrity for a potential gain in performance. If you make any change to the postback settings, it should be thoroughly tested to ensure the form behaves correctly.

    What’s next?

    The next article in our series provides information on some of the useful performance monitoring counters that can help you evaluate the performance of your form system.

  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 3)


    Part 3 – Postbacks and the conditions that make them expensive

    Welcome to the third article in our series on optimizing the performance of InfoPath browser-enabled forms. In our first article, we defined performance in terms of responsiveness (and identified postbacks as a major cause of poor performance). In our second article we listed a number of conditions that cause postbacks. This article continues our examination of postbacks, looking at conditions that make postbacks more expensive, reducing the responsiveness and scalability of a form system.

    What is an “expensive” postback?

    So what do we mean when we say a postback is “expensive”? Simply that it uses more server resources and takes more time to process the request and generate a response. For an individual form session, the result might be that form updates feel sluggish to the user. For a server processing many requests, the result might be that the performance of all requests is reduced as more resources are consumed.

    Most issues that involve expensive postbacks happen when the server must process form data changes, execute data connections, or run business logic that involves form code and event handlers. Postbacks are also more expensive when the amount of data is large, such as when there are attachments or pictures, digital signatures, or when the form is large and contains a lot of XML. Also, complicated XPaths or inefficient schema constructs demand additional processing resources. These conditions are exacerbated when they require SQL Session state management.

    The following items are some of the things that can increase the cost of postbacks.

    Session state

    For InfoPath Form Services, session state is a mechanism for maintaining the state of a form during a user’s form-filling session. For each session, it contains information about both the form data and the state of the form itself. Form Services uses session state to coordinate form changes between the browser and the form server and to improve server performance by reducing the communication required to synchronize them.

    This session state data is maintained in a SQL Server database by the Session State service, a shared service used by Form Services to keep track of open sessions for each form user connected to the server. This shared service is implemented by the underlying ASP.NET Session state for the farm rather than InfoPath Form Services, so if other Office products are deployed on the same server, the session service may also be used to maintain the state of user sessions for those applications as well. Depending on the server load, this could lead to contention for server resources between InfoPath Form Services and other products.

    Maintaining session state data in a SQL Server database helps improve network bandwidth by reducing the communication between the browser and the Web Front End (WFE) server. However, there is a cumulative performance impact on the WFE and computer running SQL Server as the number and size of the sessions increase. As a user’s session data grows, transferring, loading, and saving the session data takes longer, and more memory is consumed on the WFE. One way session size can grow happens when a user opens multiple forms in the same browser session. In this case, data for each form is combined in a single session, which reduces performance due to the large amount of session data that must be managed. The best way to avoid this condition is to add a button on the form that submits and closes the form (quitting the browser also closes the session, but adding a button allows users to keep their browser open after completing their work in the form). If the computer running SQL Server is separate from the server running Forms Services, which is common, then there is also an impact on the communication channel between the SQL Server and WFE servers. This can quickly become a bottleneck when a large number of multiple concurrent sessions must be managed.

    For smaller sessions, InfoPath Form Services can use Form View as an alternate method for managing the state of a session. Form View is implemented by using ASP.NET View State and the session data is kept as part of the HTML page and sent from the browser to the server on every postback rather than being kept in the SQL Server database. The Form View session is maintained on the browser side, and all session data is included in each postback to the server, up to a default maximum size of 40KB. If the View State session data grows above 40KB, it automatically switches to session state and is managed using the session state database on the SQL Server of the farm. Form View uses more network bandwidth than session state, but decreases load of the computer running SQL Server or the communication channel between servers. Consequently, for environments with smaller groups of users, we recommend configuring InfoPath Form Services to use Form view. For environments that must support many users, session state reduces the exchange of View State session data, reducing the size of postbacks, and generally produces the best performance.

    There are several specific conditions that increase the size of a session, making postbacks more expensive due to the added session state management load. For each postback request, the form’s state must be restored on the server, then all changes must be processed, saved, and sent back in a response to the browser. The form’s state is stored in either View state or Session state and needs to be restored by server when the next postback request for the form comes from the browser. The larger the amount of data involved, the more it slows down saving and restoring form state on each postback.

    • Data Adapters
      • When a data connection returns data, it is stored in the form’s state, either View state for small sessions or the session state database for larger sessions. The larger the amount of data, the more it slows loading and saving updates to the session state database and the form XML.

    • Attachments or pictures
      • A file attachment control increases the maximum session size by 50 percent. If the maximum size is normally set at 4MB, adding an attachment control to the form template increases it to 6MB. This additional space is allocated to accommodate the base64 encoded binary data of the attachment.

      • Consider the number of attachment controls you add to the form template, especially if the attachments or pictures might be large.

      • If you expect that number of forms sessions with large attachments or pictures will be low, the performance impact will be limited to individual editing sessions. If you expect that many of the sessions will contain large attachments, the performance hit is more likely to reduce the scalability of your form system.

      • If you need to accommodate multiple attachments, or very large attachments, you might want to investigate developing a custom solution so that attachments are not stored in the form, but are stored in a location outside the form, such as a SharePoint document library or a database.

    • Digital Signatures
      • Multiple signatures can inflate the data size of an XML form by 500KB or more for each signature. Each signature is stored as base64 encoded data.

      • Although Internet Explorer uses an ActiveX control to handle signatures and other browsers embed the signature in the form, all signatures increase the size of the session. For all browsers, the added size of forms containing digital signatures makes postbacks more expensive.

    Submitting forms to a SharePoint library

    Completed forms are commonly submitted to a SharePoint library. However, libraries are limited to 2000 documents per folder, so as this limit is approached, you will see performance problems. If you anticipate reaching that limit, you can design your form system to submit to an alternate destination. The simplest approach is to make sure that each type of form submits to a separate SharePoint library or folder rather a single library or folder containing multiple types of forms; this approach only defers the problem though. Another alternative might be to use a workflow to move submitted files from the library. A more sophisticated approach is to submit to a Web service. This will require custom development for the Web service, but it allows the most flexibility and scalability since the completed forms can be stored in either a SharePoint library or in a database. A solution that submits through a Web service to a database offers the best performance and scalability for large form systems.

    First request optimization

    InfoPath Form Services uses a technique called first request optimization to improve the loading performance of a form the first time it is requested. First request optimization involves pre-rendering an instance of the form from the form template when the form template is published. This form instance does not require a session state database entry (because there is no user session yet for an initial request). When first requested by a user, the pre-rendered instance of the form is sent to the browser for rendering so the user doesn’t have to wait while the server initializes the session and loads its version of the form.

    However, there are form features that will disable first request optimization. Initial requests for forms that cannot use first request optimization are more expensive, reducing responsiveness and slowing the loading of the form. The following conditions are examples of things that prevent this optimization:

    • The use of current time and data functions as default values

    • Secondary data source queries that execute on load (except XML files that are part of the form)

    • Rules or business logic that run on load

    • The use of a username for a default value

    • Any other environment-related or dynamic information that requires server processing

    When you publish a new form template, you can determine whether first request optimization is being used by checking for the presence of an ASP.NET session ID cookie immediately after requesting a new form (you can use an HTTP scanner tool such as Fiddler2 to check for the cookie in the response). If there is no cookie, then the form is using first request optimization. Perform an action that triggers a postback, such as switching views, and you will find a session ID cookie.

    Business logic changes to XML and cascading events

    When a postback involves business logic that makes changes to the form XML on the server, each change to the XML causes events to fire. This can cause an expensive chain of processing operations if the event handling is set up so that an XML change causes a cascade of events that make additional XML changes. Although the number of nested changes is restricted, there is no restriction on how many XML nodes are changed by a single event listener. Consequently, if an event listener changes more than one XML node and each change causes other listeners to fire and make changes to other XML nodes, then the total number of events invoked and XML changes made could be significant. The processing required to execute the cascade of events can use significant server resources, reducing throughput, scalability, and responsiveness. This situation is similar to the event handling issue discussed in the previous article on causes of postbacks, and likewise, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary server stress.

    Custom hosting pages

    Another issue discussed in the previous article on causes of postbacks addresses an advanced form scenario that involves using a custom ASP.NET page to host the InfoPath Form control. Since the emphasis here is on conditions that make postbacks more expensive, it is worth noting that although a custom solution offers significant flexibility, you also give up some of the optimizations provided for forms published using the InfoPath Form Designer. One of the optimizations you lose is that postbacks that need to communicate with the hosting page cannot communicate using partial postbacks, and instead must use more expensive full page postbacks. However, if the hosting page just needs to display a form (but doesn’t need to listen for a submit to host event), then there is no change in the form’s postback behavior and partial postbacks can be used. Also, as noted previously, with each postback there is additional processing on the server because the ASP.NET page controls must be rebuilt; and if the page is hosted on a SharePoint site, it also must initialize the complete SharePoint page infrastructure as well.

    Additional considerations

    As you might expect, this list of conditions that can make postbacks an expensive operation is not comprehensive. In fact, almost any postback can be expensive, depending on type and extent of the changes involved. We’ve highlighted some important issues above and in the previous article on postbacks. If you consider the other issues listed in that article - complex calculations and XPaths, out-of-context and multiple binding - you can see that they also imply performance and scalability impacts arising from expensive processing operations on the form server. If something causes a postback because it requires the processing power of the server, then it necessarily adds to the server load, affecting resource utilization, throughput, and scalability. These issues become more important as the number of concurrent users increases, and as the size and complexity of the forms increases.

    What’s next?

    The next article in our series on understanding and optimizing the performance of browser-enabled forms will address conditions that affect form rendering in the browser. We’ll also look at an important tool provided by the InfoPath Designer for optimizing browser-enabled forms and controlling postbacks, the Design Checker.


  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 2)


    Part 2 – Postbacks and conditions that cause them

    Welcome to the second article in our series on optimizing the performance of browser-enabled forms designed with Microsoft Office InfoPath 2007. In our first article, we defined performance in terms of responsiveness. In this article, we’ll focus on postbacks, one of the most common causes of reduced performance

    Postbacks are probably the most important factor affecting form performance because the effect of other conditions is amplified with each postback. There are two significant aspects of postbacks which we’ll examine in this series. First, which form features cause postbacks? Those features are the subject of this article. Second, what kinds of postbacks are more expensive to process, thus imposing an additional burden on the performance and scalability of the form system? We’ll examine those factors in the next article.

    What is a postback?

    Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and usually occurs when a form feature needs to send data to the server for processing. After sending the postback request, the browser must then wait for a response before it can update and re-render the form with the new data. In the case of a full-page postback, the browser must stop rendering completely until the whole updated page is returned, blocking user interaction with the form until it has been re-rendered. Alternately, to improve the user experience in the browser, some features use a partial postback, where only a specific part of the form is updated. This allows the user to continue interacting with other parts of the form while the update happens in the background. In either case, however, unnecessary postbacks impose an additional load on both the browser and the server. If you can reduce or eliminate postbacks as you design, develop, and test your forms, you can improve the performance and scalability of your entire form system.

    Browser-enabled form handling compared with InfoPath client forms

    To better understand the effects of postbacks on performance, it is helpful to compare basic form handling of the InfoPath-rich client with InfoPath Forms Services and browser-enabled forms. Whether you are new to InfoPath, or you are familiar with rich client forms but new to InfoPath Forms Services and browser-enabled forms, understanding these basic differences will help you improve your form design and troubleshooting strategies.

    The major difference between the InfoPath-rich client and browser-enabled form systems is that the InfoPath client doesn’t need to communicate with the form server as frequently as the browser does. This is because the InfoPath client processes most forms locally on the user’s computer. In contrast, the browser form relies on the server for a variety of form processing operations, requiring more communication to exchange data between the browser and the form server. Communication in the form of postbacks is a fundamental feature that allows InfoPath to support browser-enabled forms on the Web, but postbacks also make browser forms more sensitive to performance issues.

    Let’s look at two form loading and editing scenarios that further illustrate the difference between form processing in the InfoPath client and browser-enabled form systems.

    In the InfoPath-rich client scenario, when the user opens the form from a SharePoint form library, InfoPath first determines that the form should be opened in the client rather than the browser. After the initial download of a copy of the requested form template, InfoPath opens and renders an instance of the form on the user’s computer for editing. The form instance in the client is an XML document that the client renders in HTML for display. As the user interacts with the form, the InfoPath client processes and renders changes, and might run some custom form code, all within the context of the client running on the user’s computer. Generally, the only time the client needs to connect back to the server is to make additional data connection requests to query from or submit to a data source, to save a partially completed form, or to submit the final form.

    In the case of the browser-enabled form, when InfoPath Forms Services receives an initial request for the form from the browser, the server starts a session for that user’s form-filling session, allocates server resources, and processes the browser-enabled form template to load an instance of the form XML for the session. In addition, if the form requires it, the server might load and run custom form code and load data from a data source. After this initial processing, the server assembles the JavaScript and HTML that represent the form instance to be downloaded to and rendered by the browser.

    Finally, the server sends the response through a Web Front End server over the network to the browser on the user’s computer, which renders the initial download into the form view that the user interacts with. As the user interacts with the form in the browser, some form processing happens in the browser, but more complex form elements and events require a postback to the server for processing.

    During the transmission and processing of the form data, the browser instance of the form must wait for a response and then re-render the updated form. In this communication cycle, each postback request and response set constitutes a roundtrip. Each roundtrip affects the performance and scalability of the form system in terms of throughput, responsiveness, and resource utilization. This impacts both the browser side and the server side, as well as the network.

    As you can see from these two scenarios, a form-filling session in the browser-enabled form system requires substantially more communication than a similar session in the InfoPath client. In addition, more of the browser-enabled form processing is concentrated on the server, especially when multiple form-filling sessions are being served. In contrast, with an InfoPath client form, the form processing is distributed to the user systems. Consequently, reducing the number and complexity of postbacks as you’re designing browser-enabled forms can substantially boost performance.

    Ten common causes of postbacks

    1. Complex calculations

      A calculation can cause a postback when there is a condition that cannot be evaluated in the browser and requires processing by the server. For example, if a calculation requires data that is not loaded in the DOM, then the browser must send a postback to the server and wait for the result. Another condition that will invoke a postback involves any calculation that is out of the context of the current node. For example, you could create an expression such as .\.\.\my:field1+. When the expression is invoked in the form, because it requires traversing up the tree several levels from the current node, it must be sent to the server for evaluation.

    2. Data adapters

      The function of a data adapter is to make a query connection to an external data source, such as an XML file, a database, a SharePoint list, or a Web service, so that a form can receive and be updated with some data from the data source. If a form invokes a data adapter when the form loads, the browser must wait for the data connection, increasing form load time. If the form invokes a data adapter after the form loads, a postback containing the query request is first sent to the form server, which executes the data connection request on behalf of the browser form, adding additional time to the roundtrip.

    3. Multiple binding: data bound to multiple controls

      Multiple binding happens when one piece of data in the form is bound to two or more controls in the same view. This is usually done so that the same data can be displayed in multiple places. For example, you might design a report with several sections to include a single non-repeating field, such as "Report Date", inside a repeating section so that the same date is displayed in each report section. If you design a form this way, then changing the "Report Date" field in one location will update it everywhere because it is multiply bound. Unfortunately, the cost of this multiple binding might be a roundtrip to the server if the binding is more complex than the browser can resolve. In this case, server analysis is required to reliably identify all the controls bound to the same piece of data. In addition, if something is both multiply bound and out of context, then user edits to form fields will always require roundtrips. Other form actions that will cause roundtrips to the server when there is multiple binding include insertion or removal of repeating tables and repeating or optional sections.

    4. Out-of-context binding

      Out-of-context binding describes a situation where a control inside a repeating or optional section is bound to a node that is in a different part of the XML data source tree, outside the group node that contains the repeating or optional section control. When an out-of-context situation occurs in a form, the correct binding may be too complex to determine within the browser. If either the validity or the kind of action—such as a calculation—cannot be determined in the browser, the out-of context binding will trigger a roundtrip to the server to resolve the binding.

      You are most likely to encounter this problem as you’re designing a form in the InfoPath Designer if you first insert a group or control, and then later decide to move that group or control into an optional section. To avoid creating an out-of-context binding, after you drag and drop the control into the optional section, in the data source pane, drag the node the control is bound to into the group for the new optional section. The group or control will then be bound to the correct context.

    5. View switching

      Multiple views are often used to present a specific view to a specific user audience in a workflow. Multiple views are also commonly used to improve the performance of a form; by careful grouping of related items and limiting the number of controls in each view you can improve the form loading and rendering performance compared to placing everything in a single view. However, each time the view is switched, there is a full postback to send the user’s changes to the server, get the new view, and reload it in the browser. If possible, try to group the items on a view so that any controls that might postback do so when the view is switched. Then only one postback occurs when switching the view. A good example of this is using a button to invoke a query connection that returns data for a list, an operation that requires a postback. If the view is also switched when the button is clicked, you improve the efficiency of the postback. Another benefit of this design is that it makes the view switch a user-invoked action, which improves the user’s perception of the form response. By coordinating the postback of controls in the view with a view switch, you not only improve the responsiveness of the form, but also reduce stress on the server and network by eliminating extra postbacks. When designing your form there is no formula for when to use multiple views, so you will need to balance your use of multiple views with the potential design and performance advantages and costs in your user scenarios.

    6. Conditional formatting

      Conditional formatting is commonly used to hide part of a form from view until some condition is met. However, conditional formatting expressions fire every time the form is rendered whether hidden or not. Additionally, all of the data, calculations, and expressions used by fields that are conditionally hidden are still downloaded and can cause extra performance overhead. Thus if anything else invokes a postback, your form will incur this additional overhead. Similarly, if the conditional formatting requires a postback, then there is a postback each time the form is rendered. Although the primary reason for using conditional formatting has more to do with your form design and presentation, there may also be a slight increase in the responsiveness of the form if it uses conditional formatting. This is possible because it can be slower to render something in the browser than to execute the conditional formatting. However, if you need to substantially limit the presentation, consider using multiple views instead of conditional formatting because multiple views generally perform better.

    7. Digital signatures

      For forms that are filled out in Internet Explorer, signing a form uses an ActiveX control that communicates with the server using out-of-band postbacks. The signature operation involves 3 main steps:

      1. Gather client-specific information to be used by the signature data
      2. Server preprocessing to prepare the stored XML document for signing
      3. Apply the final signature

      Each step causes a postback, the first and the last being relatively expensive. This is because the first postback sends, among other things, the data corresponding to the non-repudiation image to be stored in the signature. The last is a full postback that refreshes the browser with the new signed document that has been prepared on the server.

    8. Business logic event handling

      Normally, when a user changes the values of several controls in the browser form, the JavaScript form logic in the browser can optimize the changes, batching them together to avoid a postback for each change. This reduces the number of postbacks to one. However, this optimization is not possible if the form has code or other logic, such as rules or conditional formatting, that listens to data changes in parts of the XML DOM. For example, if a control is bound to a particular DOM element and a listener is present, changes in that control are immediately communicated to the server and the corresponding event handler invoked. The number of extra postbacks depends not only on the number of event handlers, but also on the XPath they use to listen to DOM events. This is because InfoPath XML events bubble. For example, if some form code has business logic with an event handler that listens to a node close to the root node, there will be relatively more postbacks. This is because any browser change affecting one of the descendants of that node will trigger a postback to the server. Consequently, if your form uses form code or any other construct that involves listening to changes, it is important for performance and scalability that you understand and carefully scope events to reduce unnecessary postbacks and server stress.

    9. Custom hosting pages and external page events

      If you are using advanced form techniques such as developing your own ASP.NET page to host the InfoPath Form control, then there are a couple of things you should be aware of. Submitting to a custom hosting page requires full page postback because the XmlFormView control resides on the server and it involves rebuilding the page controls by ASP.NET. In addition, when submitting the form, before the submit is finalized, data is sent back to the browser with a pending submit action added. This pending submit action must then be sent back to the server in another postback to actually complete the submission. If the page is hosted on a SharePoint site, it also must initialize the SharePoint page infrastructure as well. Also, if an XmlFormView control is hosted on a custom ASPX page and the page listens to events from the control, then every operation triggering an event in the XmlFormView control will require full page postback.

    10. Complex XPaths

      In some advanced form design scenarios, you might build your own complex custom expressions or calculations using the "Edit XPath (advanced)" option. Although most common expressions or calculations can run in the browser, those that require more complex XPaths to evaluate may need to postback to the server. The following complex XPath conditions will cause extra postbacks:

      • More than one possible context for a filter
      • Complex XPath that is not used as a filter
      • XPath where the user input  is not a filter
      • XPath filter or rule that references an element that is not in the current view
      • XPath filter that is position-based
      • XPath with inline functions
      • XPath that includes an unrecognized function
      • XPath that includes an extension function that is not supported by the browser
      • XPath has an inner expression
      • Expressions containing inner nodes


    What’s next?

    In our next article we’ll examine some of the conditions that make postbacks more expensive and that affect the performance and scalability of a server system running InfoPath Forms Services.



  • Microsoft InfoPath 2010

    Designing browser-enabled forms for performance in InfoPath Forms Services (Part 1)


    Part 1 - Introduction

    InfoPath Forms Services (IPFS) is a Web service system integrated with SharePoint that enables you to deliver InfoPath forms on the Web through a browser. These browser-enabled forms extend the reach of your forms system, since your users do not require the InfoPath rich client to display and fill out the forms. When you are designing browser-enabled forms, optimizing performance should be an important objective for delivering the best possible form filling experience to your users.
    To help you reach this objective, we are introducing a series of articles about optimizing the performance of InfoPath browser-enabled forms. We will cover design issues and enhancements that can either degrade or improve the performance of your InfoPath forms system. Information in this series will help you gain a better understanding of differences between an InfoPath rich client form and a browser-enabled form, the interaction between the browser and the IPFS server system, what form features cause postbacks, factors affecting the rendering of a form in the browser, how to identify problems and monitor the performance of your forms system, and other tips for improving the performance of browser-enabled forms.

    Who should read this?

    Who should read this series about designing InfoPath browser-enabled forms for improved performance and scalability? First, anyone who is interested in learning more about the design and delivery of  InfoPath forms on the Web. Second, anyone who has to design and support large or complex forms. Third, anyone who needs to support a significant number of concurrent form users and is concerned with the performance and scalability of their Web form system under load. Whether you are an experienced form designer or are new to InfoPath, the information in this series will help you improve your understanding and control of the behavior of your InfoPath browser-enabled forms.

    What do we mean by "performance"?

    When describing the behavior of InfoPath browser-enabled forms on the Web, what do we mean by "performance"? Simply put, "performance" is the subjective perception of how responsive the form feels for the person filling it out in their browser. This perception is influenced by how quickly the form loads and how quickly it reacts to the user's input. Performance is good when your users don't have to wait for a form; it is bad when they do. As a form designer, your primary goal is to manage the overall user experience, and your primary performance goal is to minimize the time your users spend interacting with the forms. At the same time, it is equally important that your server system be able to scale to meet expected demand while maintaining an acceptable level of responsiveness. Of course, these are not your only goals - you must also deliver a form that meets a stringent set of design, business, and technical requirements. 
    Just as good form design requires balancing design and layout with business and technical requirements, good form performance happens as the result of a complex set of factors. Some of these factors might be outside of your direct control as a designer, but they must be considered in your design to achieve your performance goals. Some of these factors include:  the user environment, expected usage patterns, peak loads, network and server architecture, database design, custom code, and interaction with other applications in your SharePoint environment. The more you know about these factors of your form deployment and how they interact with your form design, the more effectively you can manage the issues that affect browser form performance. 
    Generally speaking, some of the most important objective measures for gauging performance are response time, throughput, and resource utilization. These measures can be used on the server to evaluate how efficiently requests are being processed. They can also provide insight about whether an issue is occurring on the server or in the browser. Use these measures to analyze actual performance, develop baselines, and understand the effect of your changes during troubleshooting and tuning activities. Although beyond the scope of this series, as you develop your framework for evaluating forms performance under various conditions, you should plan on developing load, stress, and capacity testing around these measures. The more objective you can become about performance, the more effective you will become at finding and removing performance bottlenecks. Later in this series you will learn more about tools for monitoring the performance your InfoPath forms system.
    Ultimately, because each environment and set of form requirements is unique, there is little prescriptive guidance that is both general and specific enough to be useful. As you optimize rendering performance in the browser, throughput might increase, but certain improvements in throughput might in turn reduce the responsiveness of a form in the browser. Or it might increase resource utilization on the server, reducing the server's ability to scale when subjected to heavy loads. In the end, you must make decisions and tradeoffs to resolve the various elements of form design with respect to the characteristics of your system, and your design, business, and performance goals. Armed with the information presented in this series of articles, you will be better equipped to make decisions that improve the performance of your InfoPath browser-enabled forms.

    Common causes of poor performance

    There are many conditions that can put a drag on the performance of browser-enabled forms in an InfoPath Form Services system. The following list is a sample of some of the most common conditions:

    • Slow network connections
    • This is an important factor in the actual performance of any server system, especially one that uses the Web. It’s something you should keep in mind as you design, test, and deploy any web-enabled form. Although there are many things that affect performance at the network and system level, and that can be done to improve it, these are beyond the scope of this series.

    • Large amount of HTML
    • Large forms that require large amounts of HTML to be transferred and rendered reduce the responsiveness of a browser-enabled form. Rendering performance will be the subject of an article in this series.

    • Large amount of XML
    • Again, large, complex forms can contribute to poor performance of an InfoPath Forms Services form system. Since Forms Services processes form XML on the server, forms with large amounts of complex XML require additional server resources. When there are many concurrent users, the additional stress on the server reduces scalability and throughput, and increases latency. In addition, a large amount of XML can slow form rendering in the browser. In this series we’ll look at a number of issues that make form processing more expensive.

    • Form features that cause postbacks
    • Certain form controls, actions, and features require the browser to communicate with the server during the form-filling session. This exchange of data during the session is called a postback, and it usually occurs when a form feature needs to send data to the server for processing and then has to wait for a response to update and re-render the form. We’ll look at specific features that cause postbacks in our next article.


    What's next?

    The next article in this series will look at some of the differences between InfoPath rich client forms and browser-enabled forms that have implications for performance. The most significant difference involves the postbacks that the browser sends to the server for processing. Whether you are familiar with InfoPath or you are new, you will learn something new and useful about the interaction between the browser and the InfoPath Forms Sevices server system.


  • Microsoft InfoPath 2010

    “Invalid Data” error when calculating the result of 2 or more fields


    When you create a calculated field in an InfoPath XML node (field) you may find that some of the resulting calculations produce an “Invalid Data” error:


    This behavior is a known issue when doing floating point calculations and is *not* specific to InfoPath or Microsoft for that matter. The floating point calculation behavior is explained in detail in several articles on the Internet; however, here are a few for reference:

    Sun Microsystems: What Every Computer Scientist Should Know About Floating-Point Arithmetic

    Lahey Computer Systems: The Perils Of Floating Point

    To create a sample of the above result:

    - Create a new SQL Server or Access database table named: FloatingPointTest

    - Add the following fields and data types:

    • ID (Int, No Nulls, Primary Key)
    • Quantity (Int)
    • Price (Money)
    • Total (Money)

    - Create an InfoPath Form Template based on this table

    - When complete, your data source should look like this:


    - Add the “FloatingPointTest” repeating group to the View as Repeating Section with Controls

    - Set the Default Value property of the Total field to the expression: Quantity * Price


    - Preview the form

    - Enter a value of 1 for the quantity and 2346.76 for the Price – result: the Total field displays the correct result

    - Modify the quantity to a value of 6 – result: the Total field displays the correct result but the control has a red-dashed border indicating an invalid value.


    The reason why the invalid data appears on some values and not on others has to do with the representation of the floating point value. For example, values ending in .25 (1/4 fraction or multiples of it) can be represented exactly, while other values cannot. The following link from the Microsoft Knowledge Base provides a Tutorial to Understand IEEE Floating-Point Errors.

    Tutorial to Understand IEEE Floating-Point Errors

    This behavior is easily corrected in InfoPath by modifying the calculation to use the “round” function. In this sample, we are looking to have a result with 2 decimal places –as such, our expression would be modified to: round((@Quantity * @Price) * 100) * .01


    After making this modification and previewing the form, the same test values now produce a valid result:


    Dragos Barac
    Senior Development Lead
    Filed Under: Controls, Formulas and XPath

Page 3 of 12 (298 items) 12345»