Microsoft Dynamics AX 2012: Client Performance Options


Microsoft Dynamics AX 2012 includes many UX enhancements, such as list pages, ribbons, fact boxes, preview panes, fast tabs, etc. These UX enhancements can help present relevant information at one place and reduce form switches. However, they come with certain performance characteristics. In this post, we’ll explain some of the issues and how to fix them with Client Performance Options.

Potential issues with Factboxes and Preview Panes

In the following figure, you can see the layout of a typical AX2012 list page, e.g. the Customer list page. In the center of the screen is the customer list itself. On the right side of it you can find a series of Factboxes, which present various information about the highlighted customer, such as its address, recent activities, statistics, etc. On the bottom of the list you can find the Preview Pane, which shows some detail information about the customer.




These information can be very helpful if you need to quickly find out some facts about the customer without opening the detail form. However, from a performance point of view, it has the following potential issues:

  • Each factbox and the preview pane is a separate form, so you will incur cost of form initialization (FormInit) and rendering (FormRun) for each and every one of them;
  • Factboxes and preview pane are rendered sequentially one by one;
  • If a factbox is expanded and it includes a  SQL query, such as the 3 factboxes shown in the above picture, each will send the query to AOS and SQL and increase load on the servers. In fact, some of the factbox queries include summary information and are quite expensive from SQL perspective.


Client Performance Options

To mitigate these performance issues, there are a few options.

For partners/developers, you can change the form and remove unnecessary factboxes. You should also make sure the query for the factboxes performs well, especially when there are a lot of data and a lot of users running the form.

For users, you can collapse less frequently used factboxes using the ^ symbol on the top right corner of the factbox. When you collapse a factbox, it no longer executes its query, thus reducing impact to SQL server. However, FormInit is still called. You can also Hide the factbox using the rectangle symbol on the left of the ^ symbol. When you hide a factbox, no FormInit or query cost will be incurred. This is a per user and per form setting, i.e. your setting only affect you and only affect this form.

For System Admin, if you want to set up performance settings system wide, open the Client Performance Options form from System Administration\Setup\System:


There are 4 options here. You can uncheck the Factboxes and Preview Pane Enabled options to remove them from the entire system. You’ll need to restart the client to pick up the change. After removing factboxes and preview pane, the CustListPage look like the following. You get more screen real estate for the list and it loads faster.




There’s also a Timeout setting for Factboxes. If you set it to a non-zero value, it will limit the time SQL server spend on the factbox queries. If SQL server can not finish the query within the timeout limit (e.g. 1 second as shown on my system), the query is cancelled. This will limit the load on SQL server and the response time on the form UI.

Comments (7)

  1. Kurt Hatlevik says:

    Thank you Tao for posting this.  But in generally it is not related to the performance of the query or the SQL server, but the performance of SysSetupFormRun.loadUsersettings() and the rendering of the client-form.  Is there any way to keep all this nice new features and controlls, but still get acceptable performance ?  I have tried to go as deep as possible, but ends up in kernel-classes, that we partners don't have access to.  

  2. Kurt,

    As I mentioned in the post, the initialization and rendering of the factboxes are sequential, so the more factboxes you add to the form the slower it gets. Unless we fundamentally change that design (i.e. make the form rendering async, as we do in EP), this fact will not change.

    I do not see the loadUserSettings issue. If you use our TraceParser to analyze the trace, you'll see that majority of time is spent in FormDataSource query, and the rest of it on Form init and Form run for each of the forms. (Yes, each fact box is a separate form.)

  3. There is a new option since R2,  "Form pre-loading enabled"  – what does this do?

  4. Koushik Talukder says:

    To kjvogt – The "Form Preload" setting is apparently the culprit behind an occasional issue where a form comes up blank and unresponsive to user input.   I have been advised to keep this un-checked until MS fixes the underlying cause.

  5. Finning Consultant - Diego says:

    Hi there, I'm supporting an AX 2012 R2 deployment for Finning and there is an overall recommendation not to use the rich client over a WAN network, or when latency and bandwidth are beyond certain threshold. Is there any practical recommendation or configuration to follow regarding this? We are being instructed to use terminal services for our deployment, buy we would like to have more independient feedback before going that way. Thanks in advance! Diego

  6. JohnLBevan says:

    Regarding the "Automatic Enhanced Previews Available" option, does anyone know what affect that setting has?  Sadly Google returns no results for that phrase.

  7. JohnLBevan says:

    FYI: We looked into disabling all factboxes for all users whilst ensuring they could re-enable them; i.e. this way new users get performance by default, and only add in those factboxes which they find useful (they're more likely to do this than the other way round).  

    Our PoC suggests this is possible / we'll be creating a job to do this soon.  The job will take copy the factbox preferences from a template user and copy them to all other users.  Once a user's had their preferences "reset" we'll flag their account so that they don't get reset again on a future iteration (i.e. so new users get the benefit, whilst existing users can restore any factboxes they wish).  Essentially this simply changes the behaviour of factboxes from on by default to off by default.


Skip to main content