Changes to Personalization in Dynamics 365 for Operations (AX7) Release
I recently attended Microsoft’s Technical Conference for Dynamics AX. All of the sessions I attended were focused on the Dynamics for Operations (AX7), which had released to the web the week of the conference. The sessions were fantastic. One of the interesting things I had not heard anything about prior to the conference revolved around the changes to personalization. A couple of the presenters mentioned that personalization should not need to be deleted anymore when code is pushed to production. The presenters said this as a side, small comment but to me it was huge. I immediately wanted to dig into what had been done!
What is Personalization in Dynamics AX?
If you are not familiar with the scenario I am describing let me explain it before going much further. In AX production environments it is common for users to hide fields, add fields, move columns around – really tailor forms to their preferences. I personally feel it is a very strong feature in AX. The tailoring done by users to their forms gets saved in tables as data, similar to how sales orders are saved in tables as data. I believe the whole form and all of its changes are saved in the personalization data. Issues with the personalization features come in when companies have developers making changes in development environments to the forms users have been personalizing. Developers may fundamentally change the forms that have been personalized by removing or adding fields from the form, or completely changing what the form’s design is. Eventually the changes made to those forms make their way into production. At this time the personalization data for the form will conflict with what the new version of the form amounts to. For example, if a user had previously personalized a form by adding a field to the form and now that field is not in the form, there is going to be a problem. Because the likelihood of having a conflict is high, most companies routinely delete all of their personalizations each time they push new code into their production environments. Once the data is deleted, the users have to go back into the production environment and reset their personalization. This problem is what they have made adjustments for in the newest version of Dynamics AX.
How Personalization in Dynamics AX has Changed
The conference presenters did not clarify what changes have been made in order to tackle the issue I just described, so I have done some digging into it. In Dynamics AX 2012 and all previous versions of AX, personalization data is stored in the table SysLastValue. In the SysLastValue table, I believe AX stored the full form and the changes within it. This means if anything in the form’s design has changed, there will be a conflict with the personalization data. In the Dynamics 365 for Operations (AX7) the SysLastValue table and the classes that call into it are gone. The SysLastValue objects appear to have been replaced by a few different tables and classes prefixed with FormRunConfiguration. The main table appears to be FormRunConfigurationProperty. This table stores what has been changed to specific controls within a form rather than storing the whole form and all of the changes to it. Changing the granularity of what AX stores in those tables means conflicts should only arise when the personalization specifically conflicts with the development change to individual controls in the form. I did not dig into whether or not Microsoft has made changes to detect what the conflict is between the controls and to try to adjust to it automatically. If they have built some logic like that, the problem should be completely gone. Even if they have not built this kind of logic, just changing the level of granularity will certainly be a huge improvement. I’m looking forward to seeing it in action!