Customizations, Configurations, Personalizations Oh My
This document is about Profile Configurations and how developers can avoid confusion when working on User Interface(UI) customizations and upgrades. You will learn what Configurations are, on a high level, and how they are stored, how they are created, modified, deleted, imported and exported. You will learn why all upgrades involving RTC(especially “RTC to RTC” upgrades) will involve discussions and analysis focusing on Profile Configurations.
This document is written for NAV developers. There are many documents that you will find with more specific and detailed tutorials for an Administrator or User’s benefit.
The major points I’m making with this document:
- The difference between Customizations, Personalizations and Configurations.
- Why Profile Configurations need to be considered in all UI customizations to pages.
- How Profile Configurations are managed in RTC to RTC upgrades.
In Classic NAV, users can customize a few visual aspects of the UI, i.e., Show/Hide Columns etc… and these “customizations” would be stored in the ZUP. In RTC, these types of changes are called Personalizations and Configurations and can be applied to virtually all visual controls of any Page, not just Show/Hide on a column or resizing forms. In fact, in many cases, what would require a customization in Classic can now be a Personalization or Configuration done by an Administrator or even a User. Users have access to several UI “Customizations” simply by selecting a dropdown menu on the UI.
As a general rule:
“If a client request can be implemented via a Configuration or a Personalization, avoid Object Customization”.
However, it could be a matter of convenience, efficiency and/or cost. If a customization is requested that encompasses all users, it could be easier to modify the object than to modify every Profile Configuration. Another consideration is that Object customizations need to be forever managed/merged in future upgrades. On the other hand, some clients might want the control they have over their users UI and will be happy to spend hours configuring their system. The challenge as developers will be how to identify the best option when receiving requests, especially in client environments that could potentially have a complex collection of Profile Configurations.
Adding to the challenge for developers is the fact that users, as well as consultants and even developers will interchangeably use these 3 terms, Customizations, Configurations and Personalizations loosely when describing a request or suggested behavior. Developers need to be able to decipher the nuances involved in each term before determining if a customization is even needed to satisfy the request.
- Customization(Object Level) - Any change made to an object including a Page Object.
- Configuration(Profile Level) - Cosmetic UI change that a Page inherits and is applied to multiple users. Configurations are stored in the database as Metadata. Profile Configurations override Object defaults.
- Personalization(User Level) - Cosmetic UI change that a Page inherits. Personalizations are stored in the database as Metadata. User Personalizations override Profile Configurations.
Another way to look at it is that there are now 3 layers involved in the UI. We now can make UI “Customizations” to all 3 layers: Pages(Object Level), Profile Configurations and User Personalizations.
If a Page has no associated Profile Configurations or User personalizations, the user sees the Page as it exists on the object level. In Classic, this would happen when the object is involved in a compile or save or the ZUP is refreshed.
What exists on the Object, can be configured in the Profile. What users can personalize depends on what is configured in the Profile. So, it is similar to Classic NAV where a user can’t use “Show” on a column that does not exist on the form, even though they may be able to view the field via zooming.
One big difference between the 3 layers is apparent when you go to perform an upgrade. Object Customizations require merging while Profile Configurations and User Personalizations do not. They adapt to the updated object changes automatically.
View and Manage Profiles via the Classic Client: Administration>Application Setup>Role Tailored Client>Profiles
Note: You can access it from RTC as well.
You will need to change the Owner ID(via the Assist Button) to the user who is configuring the Profile. The field always appears as grayed out. The Role Center Id is the Page ID that the login uses. So, if a user named Bob is assigned a Profile ID of ACCOUNTING MANAGER(as in the example Profile above), Bob’s Role Center Page would be Page 9001. When Bob logs into the RTC client, the first page that he sees is Page 9001. This is his Role Center Page. Users are assigned to Profiles in the same menu path in “User Personalization”.
To open the Profile “ACCOUNTING MANAGER” in config mode from a command line(depending on your installation and Profile ID and OS 64 or 32 bit):
"C:\Program Files (x86)\Microsoft Dynamics NAV\60\RoleTailored Client\Microsoft.Dynamics.Nav.Client.exe" -configure -profile: “ACCOUNTING MANAGER”
OR change directory first:
CD C:\Program Files (x86)\Microsoft Dynamics NAV\60\RoleTailored Client
Microsoft.Dynamics.Nav.Client.exe -configure -profile:"ACCOUNTING MANAGER"
This will open the RTC client in config mode. Now, any UI changes made during this config mode session are associated with the Profile.
Personalizations and Profile Configurations are stored in xml format in binary(blob) fields in the User Metadata and Profile Metadata tables. In both tables, the field is called “Page Metadata Delta”. As the field name implies, the RTC delta concept manages change. This allows for Personalization persistence despite future customizations.
There are some UI changes that are not retained in the Profile Metadata: Column width, caption height and page resizing are the main ones I've found. These changes are stored in %AppData%\Microsoft\Microsoft Dynamics NAV. The file is called "PersonalizationStore.xml". I found mine in C:\Users\Jon\AppData\Roaming\Microsoft\Microsoft Dynamics NAV. You can open it in Notepad, but, you don't want to. It's just a bunch of unuseable jibberish. Just know that this file stores all your trivial UI tweaks, whether you are logged in via Configuration mode or not.
Here is what the Metadata looks like exported to XML:
At this point, I cannot see that it will be beneficial to view or edit this xml manually. There is currently no known purpose for doing so.
Compiling and/or saving objects do not affect the Profile or User Metadata Delta and therefore will never affect the Profile or User Personalizations. However, if a change in the Page is introduced, either by Microsoft, a customization, or because of an Add-On, i.e., new fields in a table or new controls on a page, the metadata will resolve the delta by adding fields to the Page and therefore rendering the Page differently. For instance, this may result in new fields on Pages that have been Configured and/or Personalized to the client’s specifications. Obviously, this type of change may require further customizations if the client does not want that field visible for one or all users.
Deleting controls from Pages seems to have no adverse effect on the Metadata that involve Configurations on those controls. Although, Metadata type errors have been experienced and reported during upgrades. The errors have been few but have all involved implied references (apparently in Metadata) to objects that have been removed from the new upgraded set of objects. In my experience, the errors did not go away despite deleting the Metadata. But they did not recur in the Db at GoLive. So far, these errors cannot be duplicated in testing this exact scenario. It’s possible that unique upgrade paths have contributed to these errors. Therefore, there is not enough information to make any assumptions at this point and these errors may never happen again.
During an upgrade from RTC to RTC, it may be necessary to tweak the existing Profile Configurations to accommodate unwanted changes in the new version. During the analysis phase, this effort can be estimated to a certain degree by counting the number of objects that currently contain Profile Configurations. Table 2000000074(Profile Metadata) will contain a record for each Page that involves configurations and an associated Profile ID. Perhaps a formula for estimating effort could be “Profile Metadata”.Count * 20-30 minutes. Obviously, an upgrade that was not on RTC but moving to RTC at GoLive would not have any prior Configurations to reconcile. Also, the client may want us to perform a portion or all of these modifications or they may want to make these changes themselves.
In many cases, the Profile Configuration will be perfectly acceptable to the client in the new upgraded db. To mitigate obvious discrepancies before delivering to Test, you can open each page in the Profiles that you have determined to be affected and visually compare them to the old version. Obviously, this would require you to have access to an installed RTC client for each version.
It will be necessary to prove that you are on the correct page when viewing. To do so: select Help>About This Page. This will give you all the Page info including Object Number. This also replaces the Zoom feature from the Classic Client.
Or, you could open the Page from the Object Designer. But you will need to be sure your Profile ID is set on the User Personalization Card to the correct Profile that you are testing.
During testing, if new Profile Configurations are performed on the test db, the new Configurations will exist in the database. Since configuration changes exist in the database, similar to setup changes, they will need to be applied to the new version of the Production Db at GoLive. Fortunately, there are built in reports for importing and exporting Profile Configurations. You could use the Functions>Export Profiles, however, at least in the NAV build that I used for this document, there is no Import function. So, you can use reports 9171 “Export Profiles” and 9172 “Import Profiles”. This will be an added step for all upgrades at GoLive.
I can’t come up with a scenario where Profile Configurations should be deleted, but, the Profile Card has a function to do this. To delete Profile Configurations, you can delete directly from Table 2000000074 Profile Metadata. This table has no delete trigger code. Or you could delete using Profiles: Functions>Clear Configured Pages(this does the same thing). This method uses a Codeunit called “Conf./Personalization Mgt.”, which curiously, contains a TRUE parameter in the DELETEALL command implying that, upon deletion of Profile Metadata, the delete trigger code should be executed even though none exists. Perhaps in the future, Microsoft will add Delete trigger code on the Profile Metadata.
Here is a listing of Functions from Codeunit 9170 Conf./Personalization Mgt. :
So, that’s about it for Configurations, Personalizations and Customizations. I hope you can digest this without too much indigestion. It’s a bit convoluted but will be common sense eventually, once you get to working with the new RTC.