Why Slow Forms Happen in Microsoft Dynamics 365

A form that takes 4 seconds to open costs a few minutes per person at 50 openings a day; calculated across a whole organization, that can add up to hours per week. The causes are rarely exotic. Mostly it is the same brakes, and most of them are in the form definition, where you can count them and see them.

Every subgrid is a query

The biggest single item is subgrids. Each of them fires its own query on load, plus icons and formatting. A form with 4 subgrids therefore starts with 4 queries in addition to the actual record. And if the underlying views are built wide, with correspondingly slow ones.

Not every subgrid has to go. But each one should answer the question: is it really needed immediately on opening, or is it enough on a second tab where it only loads when needed? Because here a friendly property of the platform comes into play: content on collapsed or inactive tabs is only loaded when it is expanded. The cheapest form speed-up is therefore often pure rearranging.

The script chain on load

The second item is the OnLoad events. The problem is less many small handlers than single expensive ones: scripts that fetch server data on load, possibly several in a row or synchronously. A synchronous call blocks the form completely until the response arrives, and two of them in sequence add up visibly.

Which functions hang on the load event is in the form definition. Writing the chain down once and questioning every position is more laborious than counting subgrids, but it finds the stubborn cases.

The quiet contributors

Then there are items that are small individually and add up: very many fields on the first tab, quick view forms (each one loads its linked record as well), an elaborately configured timeline, business rules in large numbers or, for choice fields with hundreds of options, those as well. How to thin out such rules safely is described in removing old business rules.

Rollup and calculated fields are a special case: they rarely make the form slow, but they create that impression because their values appear with a delay. That is a different problem with a different solution.

One more distinction helps with the assessment: the first opening after a deployment or a browser change is always slower, because resources are freshly loaded from the server and into the cache. Anyone comparing load times should still measure the first opening, because that is exactly what users experience.

Measure instead of guessing

Before rebuilding anything, a measurement is worthwhile, and the platform provides it: the performance panel in the form (reachable through the diagnostics) shows which parts took how long. That turns the assumption that the scripts are to blame into a number, and not infrequently the number points to something other than expected.

The target is unspectacular: under two seconds, a form feels normal. You almost always get there by rearranging, thinning out and defusing one or two expensive scripts. A rebuild is rarely necessary.

Forms are where slowness is felt. Where slowness is measured, in saves, imports and lists, other components are to blame; they are ranked in which components cause poor performance. And which of these patterns can already be spotted during development is covered in detecting performance risks early.