Improving the Performance of InfoPath 2003 Forms

Summary: Learn how to avoid performance issues when designing Microsoft Office InfoPath 2003 form templates, and how to troubleshoot existing form templates that display poor performance. (15 printed pages)

Andrew Begun, Microsoft Corporation

Updated March 2007

Applies to: Microsoft Office InfoPath 2003


InfoPath Architecture and Performance Overview

Most form designers do not need to be concerned about the underlying technologies of a Microsoft Office InfoPath 2003 form template, but understanding those technologies can be useful in determining their performance implications.

When you save an InfoPath 2003 form, it is saved as an XML file that contains only the data collected by the form. The form does not contain any view, data validation, editing state, or other presentation information. The form template, on which the form is based, defines how the XML form is visualized, validated, and edited. Table 1 lists some aspects of an InfoPath 2003 form template that have potential performance implications, their associated technologies, and when they might be invoked.

Table 1. Feature areas and performance implications
Feature Technology When applicable

Form template caching and versioning

  • Network I/O operations

  • Form load

XML data processing

  • XML DOM (Document Object Model) document

  • Form load

  • Form data changes

View rendering

  • XSLT style sheet

  • XHTML (Internet Explorer)

  • Form load

  • View change

  • Form data changes


  • XSD schema

  • XML events (XPath)

  • Form load

  • Form data changes

Dynamic editing

  • XML fragments (XSF)

  • Form load

User interface interaction

  • Calculations and rules

  • XML events (XPath)

  • Form load

  • Form data changes

Custom business logic

  • Script or managed code

  • XML events (XPath)

  • Form load

  • Form data changes

  • Form template events

Data connections (Query and Submit)

  • Web services, for example, ActiveX Data Objects (ADO)

  • Network I/O operations

  • Form load

  • Form template events

The XML DOM (Document Object Model) is a primary technology in InfoPath 2003. The form load event and XML DOM changes are two areas in which performance can become an issue for an InfoPath form template.

This article provides a broad overview of performance issues in InfoPath form templates by feature area and provides troubleshooting guidelines and best practices to help reduce problems in each area. It assumes the reader is generally familiar with InfoPath feature areas.

Troubleshooting Performance Issues

Solving performance issues in any software solution can be time-consuming. InfoPath performance issues typically occur in well-known areas and conditions, and you can investigate these items systematically to improve the performance of a particular form.

The following conditions can cause poor performance in InfoPath forms:

  • Slow network connections

  • Large amount of HTML to render

  • Large amount of XML, including large form templates or manifest.xml files

In general, InfoPath features that have more than one of these conditions are more likely to cause severe performance issues within a form. A well-designed form template should limit these conditions to protect the features in the form against performance problems. When you are troubleshooting an existing form, you should consider these issues together with specific features of the form. This is often more productive than looking at them in isolation.

A decrease in performance most commonly appears in the following form operations:

  • Form load

  • View switch

  • Data connection (Query/Submit)

  • Single edit in the form user interface (UI)

For more information about how to specifically identify problems in these and other areas, see Scenario-Based Debugging. First, however, we examine the performance profile of each area in InfoPath 2003 where performance problems can occur.

Performance Profile by Feature Area

Performance issues can occur in different feature areas, depending on the size and structure of your form template. This section describes symptoms and possible ways to improve poor performance in several feature areas in InfoPath 2003.


One of the most important aspects of an InfoPath 2003 form template is how the user interacts with the XML data. In InfoPath, the designer can define views that enable the end user to edit the XML data. The views can be dynamic and include repeating and optional sections that modify the layout while the user is editing the form. A view consists of more than just the visualization of the data. It also includes the editing actions end users can take within the view, such as which controls they can edit, which sections they can insert or remove, and what XML should be added to the DOM when end users insert another table row.

An InfoPath view consists of two key pieces:

  • An XSLT file that transforms the XML data into XHTML, which is what the user sees in the InfoPath editing UI.

  • A section in the form template's form definition file (XSF), the manifest.xsf file, that defines which dynamic editing actions—such as inserting, removing, or replacing XML—are allowed within the view.

These definitions also contain the XML fragments that should be inserted into the underlying DOM when the user chooses an insert action.

View performance issues typically appear at three different times:

  • Initial view rendering time.

  • Form load time.

  • Form update time, or the time between editing the form and when those changes are reflected in the view to allow more edits to occur.

The most common way to improve view performance is to split a view into multiple views. Although this method is suggested in the next section, it is not always the correct approach. The following are some of the most problematic view performance issues with some suggested remedies.

Issue 1: Too Much HTML in One View

  • Symptoms:

    • Slow initial form load

    • Slow view switch

  • Identifying the issue:

    Because every form template is unique, guidance for limiting the number of HTML pages is not very useful. But if you are seeing slow performance when you switch to a large view, you should investigate how many pages are in the view. One good way to evaluate the size of a view is to check the size of the scrollbar in the designer rather than in the editor because sections and controls may be hidden. Although InfoPath adds some additional overhead, generally, if loading the same HTML in Internet Explorer is slow, this area requires further investigation.

  • Improving performance:

    If the view contains many controls, and especially if they are repeating controls such as the Repeating Table and Repeating Section controls, you should separate it into multiple views to reduce the amount of HTML that InfoPath is required to render.

    If you have one repeating control with many entries, try using a Master/Detail control, filtering your data before rendering occurs, or using conditional formatting to hide some data. You could also limit the number of allowable rows in the repeating control via the underlying schema or through code in an event handler for the following events:

Issue 2: Slow HTML Performance

  • Symptoms:

    • Slow initial form load

    • Slow view switch

    • Slow updates to the XML DOM

  • Identifying the issue:

    Slow HTML performance is a more subtle problem than too much HTML. Investigation usually requires examining the HTML that is generated from the XSLT file that corresponds to the view. Again, opening the resulting HTML directly in Internet Explorer is a good way to determine whether the performance issue is HTML based.

  • Improving performance:

    Limit the number of Drop-Down List Box controls that contain many items, especially within repeating controls. Microsoft Internet Explorer 6 renders each Drop-Down List Box control with its own window handle (HWND), and the HTML representation of a Drop-Down List Box with many items is significant. If a form template is likely to be used on a computer that has Internet Explorer 6 installed, you can work around this issue by using a Master/Detail control for editing the repeating control, so that only one Drop-Down List Box is in the view at any time. The master, or a print view, can contain a read-only Expression Box control that displays of the value of the drop-down list. If the Master/Detail control is not possible, a second solution is to have a Text Box or Expression Box control in the table, and use either a custom task pane or a custom dialog box with code to show the drop-down values. When the user clicks a button on the task pane or clicks OK in the dialog box, the selection is written to the XML DOM.

    Limit the use of nested layout tables, table controls, and sections within the view. Laying out the HTML is a very CPU-intensive operation, and nesting tables causes this layout time to grow non-linearly. Although nesting section controls is not as severe from a CPU perspective, you should still limit them. Ask yourself the following design questions when you are nesting controls:

    • Can I use a Repeating Section control instead of a Repeating Table control?

    • Do I need to have a layout table inside my Repeating Table control?

    • Do I need to have a layout table inside my recursive section?

    Finally, try using fixed widths instead of percentage widths for structural controls and especially nested controls. By default, InfoPath uses 100 percent width for these and other controls, because it results in the view updating with the InfoPath window size, but this is more expensive from a performance perspective during HTML layout and rendering than using a fixed width. This is especially valuable in recursive section controls and the controls within them.

Issue 3: XPaths or XSLT with Long Running Time

  • Symptoms:

    • Slow initial form load

    • Slow view switch

    • Slow updates to the XML DOM

  • Identifying the issue:

    This is rarely reported as a problem, but it can occur rather easily, especially when you are working with filters or manually modifying the XSLT. If you have done either of these, or you have added rather complex Expression Box controls in the view, then you should look more closely at what you have written. Some parts of the XPath language are dangerous, meaning that it is easy to create XPaths with O(n2) or worse running times. Having this in the view slows down the view significantly. For example, consider the following XPath that could be used in an Expression Box control to show the number of work items that are invalid because a prior work item was not approved:

    count(//my:workitem[preceding::my:workitem[@my:approved = 'false']])

    This XPath has an O(n2) running time and could lead to performance issues if the XML DOM is large.

  • Improving performance:

    There may be another way to write your XSLT or XPath to achieve the same results. If not, you either need to remove the offending XPath or restructure the XML in a way that lets you evaluate the XPath more efficiently.

    Looking back at the example XPath that counts the number of unapproved work items, you can use the following O(n) XPath to achieve the same result.

    count(/my:myFields/my:workitems/my:workitem[@my:approved = 'false'][1]/following-sibling::my:workitem)

    If you cannot simplify an XPath based on how the data is structured, consider moving it to a location in the view where it can be simplified. In the previous example, if the table of work items is inside a repeating section, the O(n) XPath would not work at the root of the view. You could modify it, however, to work as follows.

    count(my:workitems/my:workitem[@my:approved = 'false'][1]/following-sibling::my:workitem)

Data Connections

Databases, Web services, and other data stores are central to many InfoPath forms, whether they are used for querying or submitting XML data. When you are working with data connections, be aware of the following issues:

  • Data connection I/O operations are made synchronously, which means that while they are running, the end user is unable to interact with the form.

  • Queries that automatically run when the form is opened execute sequentially, so the total time it takes to query multiple data sources is the sum of calling each individually.

  • All data returned from a data connection is stored in an XML DOM.

These points should enable you to think about each data connection you make and justify its use, especially those queries that occur on load. Data connection performance problems can usually be classified into three issues: too many on load queries, a slow data connection, or too much data returned by the query.

Issue 1: Too Many On Load Queries

  • Symptom: Slow initial form load time

  • Identifying the issue:

    Any time you have more than one query that runs on form load, you should time how long they run. You can tell when a data connection is executed by looking at the InfoPath status bar. But to time them, set up a button to invoke a rule to run the query so that you can time them individually.

  • Improving performance:

    Evaluate each query for whether it must run at load time. If the data returned is shown in a Drop-Down List Box control, do not query for the data until the drop-down box is shown in the view. For example, if the drop-down box is not part of the initial view, or it is contained inside an Optional Section control, query for the data when the view is switched or when the optional section is inserted. To achieve this, make the data connection call through business logic.

    If the data for a particular data connection does not update frequently, such as a list of states and regions, consider moving the data into a static XML file that is a resource of the form template.

    Or, consider the following questions: Can you combine some of the data connections into one data connection? If you have five database queries to fetch data from different tables, can you combine it into one database call that obtains all the data at once? Alternatively, you could design a Web service that makes parallel asynchronous database calls to bring the time closer to the slowest connection, instead of the sum of all connections.

Issue 2: Slow Data Connection

  • Symptoms:

    • Slow initial form load time

    • Slow individual data connection call (for example, on a button click)

  • Identifying the issue:

    Again, the status bar shows when a data connection is occurring. If you have multiple data connections running during an event, such as load time or a button click, you can either move them into business logic and measure the time they take to complete, or you can systematically test each data connection individually by disabling the other calls.

  • Improving performance:

    Avoid making slow data connection calls on load. These are best made in response to an explicit user action such as a button click. Alternatively, you can make such calls just in time, as explained in the Data Connection Issue 1 section.

    If your form template is used infrequently, make sure that the back-end Web service is being kept alive long enough. When you make a call to a Web service that is not running, there is extra wait time as the Web service code is loaded into memory so that it can execute. If the Web service method you are using is expected to execute infrequently, you should move the method into a Web service that has frequent calls made to it.

    When the data is appearing in a Drop-Down List Box control, consider adding a Button control to populate the drop-down list. When you are opening a previously filled-out form template, it is very likely that the drop-down list will not need to be populated with values.

Issue 3: Too Much Data Returned By Query

  • Symptoms:

    • Slow initial form load time

    • Slow individual data connection call (for example, on a button click)

  • Identifying the issue:

    If data that is returned by the query is bound to a Drop-Down List Box, Repeating Section, or Repeating Table control, the amount of HTML may be causing the performance problem. For more information, see View Issue 1.

  • Improving performance:

    There is a fine line between making one query that returns too much data and making many queries over time that are not returning as much data. Which approach is better depends on the scenario of each form template, but it is often worth filtering the data on the back end, such as in the Web service or SQL query, instead of inside InfoPath. Make sure your query is scoped to the data you need, and then optimize the query performance by having the necessary indexes in the database.

    For more information, see the suggestions for View Issue 1.

File Attachment Control and Embedded Picture Control

InfoPath provides several features that add binary data to the XML form. The two most obvious controls are the File Attachment and Picture controls. When you are using these controls, be careful about how you use them in order to minimize the size of the resulting XML. It is easy to add megabytes of data to an XML form, which can greatly slow load and submit times.

Issue: Too Much Binary Data in the Form Data

  • Symptoms:

    • Slow initial form load time

    • Slower than usual submit times

  • Identifying the issue:

    It is fairly easy to see whether there is too much binary data in a form template by examining the size of the XML file saved by InfoPath.

  • Improving performance:

    Avoid using binary data controls when you expect the binary data to be large, such as high-quality digital images, large program executables, and large Office documents. In these cases, it is best to link to the file instead of adding it to the form. Although you could ask the form user to provide a URL to the file, you could also write business logic to save the file to the appropriate location and add the link to the form.

    Limit the amount of data that can be added via one of these controls by using an event handler for the following events:

    Other suggestions:

    • If too much data is being added, reject the change with a user error message.

    • Only allow compressed files, such as .zip files, to be added using the file attachment control.

    • Limit the use of binary data controls inside repeating controls.

Digital Signatures

If you have ever used digital signatures in InfoPath, you may have noticed that an image is associated with the signature. This nonrepudiation image is added to the form because the XSLT view in the form can be changed to give the XML a different meaning, without changing the XML. By adding this image, the signature includes both the XML data and the view of the data that the person signing the form agrees to. The symptoms and identification of this issue are similar to the file attachment and embedded image controls, although the mitigation methods are different.

Issue: Large Digital Signature Images Included in XML Form Data

  • Symptoms:

    • Slow initial form load time

    • Slower than usual submit times

  • Identifying the issue:

    Compare the size of the XML file before signing the form to the size of the XML file after signing the form.

  • Improving performance:

    • Narrow the scope of the signature to the portions of the view that need to be signed. Allow signing sections of the view instead of the entire view.

    • Limit the number of signatures that are added to an individual form. If necessary, have two signed copies of the form instead of one form with two different signatures.

XML Events

XML event handlers in InfoPath are a common source of bugs and performance issues for developers new to the InfoPath object model. Problems usually stem from not knowing the following two principles of InfoPath event design:

  • XML events bubble. A listener on the root of the XML document is notified of all changes in the DOM.

  • Text changes in the form typically result in two events: one for the deletion of the original text node in the XML DOM, and one for the addition of the new text node.

Not taking either or both of these principles into account leads to redundant business logic, which could lead to performance issues. The performance cost of updating a field two times is often small, but could be more significant if more business logic is invoked inside the event handler, such as querying a data source or manipulating the DOM.

Issue: Event Handler Custom Logic Running More Than Once

  • Symptoms:

    • Slow initial form load time

    • Slow changes to the XML DOM

  • Identifying the issue:

    Many times this issue manifests itself as a problem in the business logic before it causes performance issues. When adding code to an event handler, you should also add an alert dialog box or add a breakpoint in the code to ensure that it occurs when, and only when, you expect it to. If you do not take this approach and experience slow changes in the form (in particular, after adding some event handlers), you should verify that the code is running only when you expect it to.

  • Improving performance:

    For event handlers on a leaf-level element, such as one bound to a Text Box control, ensure that an edit is only executing code once per text change. You can do this by returning immediately from the event handler when the event type is a delete operation on the text node, because InfoPath never causes this to occur without also raising an insert event. Immediately after the undo/redo check that is automatically inserted in the event handler, you could use the following code.

    For managed code:

    if (e.Operation.Equals("Delete"))

    If (e.Operation.Equals("Delete") Then
    End If

    If the field being removed is important, such as data bound to an Optional Section control, you would handle the delete of the field itself. Immediately after the undo/redo check that is automatically inserted in the event handler, you could use the following code.

    For managed code:

    if (e.Operation.Equals("Delete") && e.Site != e.Source)

    If (e.Operation.Equals("Delete") And Not (e.Site Is e.Source) Then
    End If

    If an event handler is listening to a structural element—for example, one bound to a table—make sure that it is only doing work for the element and text changes that you care about. If the intent is to do work when a new row is added, make sure that no work is done when a text value change or other structural changes inside the row are made. There are cases in which it is a good idea to add a higher-level listener to filter on the events bubbling up. If you do this, you must also explicitly handle the changes you are targeting, because more events will bubble through this higher-level handler.

Making Many XML DOM Changes


This issue is fixed for all releases of InfoPath 2003 by installing the update described in the support article Description of the update for InfoPath 2003. This is not an issue in Microsoft Office InfoPath 2007.

Every time that an XML DOM in InfoPath is modified, a series of events is fired to various listeners in your custom business logic and within the InfoPath application itself, for example, in InfoPath's validation and calculation engines. Some of these listeners evaluate all DOM changes, while others are only listening for changes that match certain XPath queries. In either case, it means that there is no such thing as a cost-free XML change inside an InfoPath DOM. In most cases doing bulk edits in a temporary DOM and then inserting it into the correct location in the form template's DOM is faster than making individual modifications directly against the form template's DOM. Sometimes a making a bulk insertion into the form template's DOM may exacerbate other performance issues, such as those caused by a large number of event listeners and declarative features like calculations, but performance is still better than making DOM changes individually.

Managed Code

The ability to use managed code instead of script for the business logic of an InfoPath form template unlocks many scenarios that were either difficult or impossible with script. Writing managed code also provides a better design and debugging experience than writing script with the Microsoft Script Editor. Managed-code forms, however, have a longer startup time than a comparable form based on script. The difference depends on the speed of the computer where the form is being used. Make sure that you test your form on a typical end-user computer, and decide whether the startup time is acceptable for the added benefits of using managed code.

Deployment Methods

When loading a form template for the first time, InfoPath caches the form template locally on the user's computer so that opening the XML in the future does not depend on network connectivity or re-downloading the entire solution. During subsequent loads, depending on the method by which the form template was deployed, InfoPath may check the time stamp of the original XSN to see whether it has changed since the time it was added to the form template cache. If the solution is published to a location that may be accessed by some users over a slow connection, loading forms and creating forms with that form template will also take longer for these users. Be aware that the method of deployment can affect the security level of your form template and therefore, the feature set the form template can use.

Issue: Deployment Method is Causing Slower Load Times

  • Symptom:

    Slow initial form load time

  • Identifying the issue:

    Some users experience longer load times, especially the first time the form template is used, compared to other users. Test different computers at different locations, if possible. Additionally, you should use Internet Explorer to download the form template from the published location, because it may take longer than expected.

  • Improving performance:

    Publish the form template to a server that has a fast connection for all users. If no single location works, consider deploying the form template to multiple locations. This approach works best when the XML is being submitted to a single database or Web server and not reloaded into InfoPath, or when the XML created from a form template in one location will be used by people who have quick access to that location.

    If you do not need to update a form template, and you are not using data connections, consider using e-mail to deploy the form template instead of publishing it to a shared location. This avoids the initial download slowness and future network checks for new versions.

    Form templates can be installed locally on each computer by a user or service that has administrative credentials using a Microsoft Windows Installer (.msi) file created with the Form Registration Tool or a script file. This deployment method is typically reserved for form templates that require full trust as an alternative to digitally signing the form template, but it does have the added benefit of correcting this performance issue.


    For information about how to use the Form Registration Tool, see Using the Form Registration Tool [InfoPath 2003 SDK Documentation].

Schema, Template, and Fragments

The schema that is used for the solution can have a large impact on the performance of the solution and ultimately the way the form template is designed. Just as pruning unnecessary elements from the fragments is important, so is removing unnecessary elements from the template.xml file from which all new forms are created. To view and edit the default values defined in the template.xml file, click the Default Values command on the Tools menu in the InfoPath design user interface. Other than this, the only performance-related advice for schemas is to keep them as tightly scoped for the form template as possible. If you are designing a form template for part of a large and complex schema, it might be better to use a trimmed-down version of the schema that represents the part you are editing. Or, you can create a different schema in InfoPath and transform the data by using an XSLT or some other mechanism to re-create the larger schema upon submission.

Master/Detail and Filters

The Master/Detail control and filtering features that were added in InfoPath 2003 SP1 are great features for making form templates more user and performance friendly. When you are using these features, be aware of the following issues regarding performance:

  • Just because you do not see something in the view does not mean that it is not in the data. The ultimate size of the XML affects performance in subtle ways, including the overall working set used by the XML DOM and the speed at which certain XPath queries execute. When details contain a large amount of data, consider fetching the data on demand from a secondary data source and then either displaying it in the current form or opening a new form template with that data.

  • Keep filter and Master/Detail control constraints as simple as possible. As previously noted in Issue 3 of the Views section, XPaths can have very slow running times when constructed incorrectly. By keeping the constraints simple you are less likely to encounter this issue.

Recursive Sections

Recursive sections are a great feature but do require some extra attention when you are creating a form template. Recursive sections tend to cause view slowdown due to nested tables and sections. Try to use Section controls instead of tables inside nested sections, and use fixed widths instead of percentage widths within recursive sections. Whether using fixed widths or percentage widths, you should always test your form template to determine when the XML nesting becomes too deep for either performance or usability reasons. If you think users will reach this level of recursion, you should add an event handler for the OnBeforeChange (script) or OnBeforeChange (managed code) events to reject the addition of recursive sections after the acceptable level.

Scenario-Based Debugging

The following sections provide testing scenarios to help you debug performance issues that can occur when loading forms, switching views, working with data connections, or handling events.

Form Load

Debugging form load performance issues is typically the most difficult performance investigation task because there are many potential causes, and it is difficult to isolate each one during load. Prescriptive guidance when you are facing a slow load-time problem is to list the issues that may be adding to or causing the problem and try to measure their performance outside load time. Begin by using the suggestions in the Performance Profile by Feature Area section and make a list of potential issues in your form template during load.

After you have compiled this list, try using the following suggestions to determine which feature is causing the problem:

  • Create an empty view and make it the default. If loading the form template to an empty view is quick, examine the initial view for view-based performance problems. Remember that issues can be cumulative, so that if switching to the view is not slow and load time is now acceptable, you might consider creating a simple initial view, such as a "Welcome" page that contains a Button control to switch to your first view.

  • Set all data connections to not query on load. If load time improves, test load time with one of the data connections turned on and iterate over each of them to determine which ones are causing performance issues.

  • If the form template has an event handler for the OnLoad (script) or OnLoad (managed code) event, comment out this code. If the performance improves, uncomment some of the code to determine which portion is causing the problem.

  • If the form template has many views, create a version with only one view to see whether your issue is caused by having too many views in the form template.

  • Run the form template locally (published or saved to your local computer) to see whether the published location or deployment method is causing performance issues.

  • If you still cannot determine the source of the issue, it could be due to a declarative feature such as calculations. Try extracting the files in the form template to a folder using the Extract Form Files command on the File menu. Then open the XSF file (manifest.xsf) and comment out the declarative features to see if they are having an effect on performance.

View Switches

Performance issues when switching views are relatively easy to troubleshoot. You can start with the following areas:

  • If the form template has an event handler for view switches, try commenting out the code in the handler a see if the problem persists. Add the code back, piece by piece, to determine what is causing the problem.

  • Read through the information about views and recursive sections in the Performance Profile by Feature Area section.

Data Connection (Query/Submit)

The most important thing to remember when you are investigating data connection issues is that the issue can be in various places:

  • A performance issue within the InfoPath form template, including issues in a submit event handler.

  • An issue on the back-end implementation of the data connection.

  • A network issue between the end user's computer and the server.

If you do not control or cannot make changes on the server, there are ways to reduce the performance issues, as discussed in the Data Connections section.

Event Handlers

When a change occurs in the DOM, there are a few event handler-related issues that could cause performance problems. The first issue is discussed in the XML Events section, namely redundancy of work inside event handlers.

The second issue is one that deals with InfoPath instead of your form template. If a form template has many event handlers, any change to the DOM can take a long time to commit. This issue is multiplied by the size of change to the DOM. If you are investigating a DOM change that is taking much longer than expected, and you suspect an event handler issue, consider the following:

  • Do you have any XML business-logic event handlers that are triggered for that part of the DOM? If so, try the suggestions in the XML Events section.

  • Do you have many features that rely on XML event handlers, including business logic event handlers, calculations, and rules? If this is the case, try reducing the number of these features by moving them into business logic and collapsing the number of business logic event handlers by merging them into a larger event handler that listens to an ancestor, and taking action by evaluating the source of the event.


Designing an InfoPath form template for better performance requires you to be careful with the size and number of views, the size and structure of the XML, and the number of file and picture controls you use. You also must be wary of the structure of your digital signatures and the size and number of data connections in the form. By following the guidelines and best practices in this article, you can avoid performance problems when you are designing a form template and troubleshoot the same problems in existing form templates.

Additional Resources

For more information about InfoPath, see the following resources: