A look under the hood – form load from Outlook

Ok, so we all know, we click a link, a page loads, and voila. But what is going on behind the scenes, and especially what is going on in Dynamics CRM when working from within Outlook? Well, let’s see.

There are a few steps taking place here. They are:

  • Start the Form Load
  • Retrieve the Entity Layout and Metadata
  • Data Binding and show the form in read-only
  • Make the form read/write
  • Initialize the sub-grids and the social pane where available
  • Execute JScript web resources

As you can see, there’s quire a bit happening. Let’s look at each one of these steps in detail, to see what happens and where things could go wonky.

Starting the Form Load

First off, it all begins with a HTTP GET request. This request is issued to the main.aspx URL. The server receives the request, and responds back with an HTML response. This response contains the following items:

  • entity instance data
  • configuration values
  • scripts and css tags for references

Once all this data makes it back to the browser, global.ashx takes control and starts the execution locally.

Retrieve the Entity Layout and Metadata

Once global.ashx starts execution, first thing it does is to pull the entity metadata and layout from the browser’s cache. The layout is simple HTML.

Data Binding and show the form in read-only

Once the layout is retrieved, and the record data is available, binding these results in HTML that is being rendered and shown to the user. Here, all the data is presented on the form, in a ReadyState state. This is also called ViewReady. Note that this is read-only.

Make the form read/write

For a short period of time, if we were to slow time down and observe, the form would be in read-only mode. All data is available on the form.

In order to make all the controls presenting data read-write, some more steps need to take place. These include:

  • Download additional JScript libraries that include controls logic.
  • Execute all scripts in sequence.

Note that all scripts, once loaded, are cached on the browser. For this reason, the initial form loads are always slower that subsequent form loads.

Initialize the sub-grids and the social pane where available

At this point, Ajax requests are being sent out and data is being retrieved for all grid controls and the social pane. At this point the controls get populated with the retrieved data, and the for is ready for the user.

Execute JScript web resources

Now that the form is fully initialized, the control is passed to the web resources registered on the form. These include standard out of the box resources, as well as custom resources. At this point all your custom scripts will execute, and filters can be applied on data grids to modify the default data shown. For this reason, when loading a form you will see another blip on your screen when you have customized the data to be shown in grids.


As you can see, there is quite a lot happening when you simply retrieve an entity record. All these requests, all the resources being downloaded, these all take time. As such, the more data is being captured/shown on a form, the more scripts are added to a form, the connection speed, the server load, the performance of the local machine, these can all influence the overall performance from a user experience point of view.

Don’t forget: Less is More. Take a minimalistic approach to customization for better performance and user experience.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a website or blog at WordPress.com

Up ↑

%d bloggers like this: