Big forms: How big is too big?

Unfortunately there is no clear-cut answer to the question of what precisely makes an InfoPath form too big or too complex to work as a Formotus form on a mobile device. This article is intended to give some helpful understanding of the question and the factors involved.

What happens if a form is too big and complex?

When InfoPath forms become too large and complex, the symptoms can show at different places: 

  • Failure to upload to the cloud console, usually because of form complexity (rules, containers, etc. - see below)
  • Failure to open on the mobile device, usually because of limited memory resources on the device
  • Failure to submit from the mobile device, usually because of a connection failure while sending a large file

What factors are known to make a form too big and complex?

View length

Very large InfoPath views can cause problems on mobile devices because the entire view must be loaded in memory at once. Our first suggestion for a problem form is often to split a very long view into multiple shorter views.

Number of fields

A form with 100-200 fields is a pretty large form but can work if it's designed right. We've seen forms with 500 and even 1,500 fields, and those have not worked.

Number of controls (avoid radio buttons)

A form with 100 fields bound to 100 controls is lighter than a form with 100 fields and 300 radio buttons to set the values. For this reason dropdown lists are preferred over radio buttons in big forms.

File sizes

Forms that are heavy with images can become quite large files. A form with an XSN file over a megabyte is a pretty large form, but doable. We've seen forms that do work in the 5-6 MB size range for displaying images, but submitting large image files would be another story.

Tip: Avoid pasting large images into your form and then resizing them smaller in the InfoPath layout, because the file size will be large even though the visual  image is small. Instead, resize and save images to smaller files outside InfoPath, then paste them in.

Number and complexity of containers

Three kinds of containers are complex structures that should be used sparingly and separately:

  • Repeating tables and sections, which let users add unlimited new items
  • Optional sections, which can be added or removed by users
  • Formotus custom control template part sections, which enable features such as ink, photo and GPS.

Rules of thumb:

  • Avoid repeating-in-repeating if possible, or approach cautiously and keep it simple inside.
  • Avoid Formotus controls in repeating containers.
  • Avoid nesting any section-in-section-in-section. Keep it limited to 2 levels, not 3. (Note: Nest groups in the data structure as deep as you want, just don't nest sections in the layout.)
  • Avoid optional sections unless necessary. Usually you can substitute a normal section with a rule that hides it when not needed, and this will be more robust.

Number and complexity of rules

A form with many complex rules can be a problem, especially if combined with other factors such as a large number of fields. Think twice about designing a form with features like these, which we have seen fail:

  • Many dozens of fields that each have complex calculated default values
  • Rules that each include over 100 actions to set field values
  • A drop down list box selection that's expected to fire over a dozen different rules
  • Rule chains across more than 2 controls (e.g. button A sets field B which causes field C to change, which causes something else)


Have more questions? Submit a request


Please sign in to leave a comment.