I’ve been always wondering if editing a customizations file should be considered an “unsupported” customizations. That was sort of my gut feeling since, after all, that file is rather complex, and it’s not something you can edit easily – you have to go over a few steps to even get that file, and, then, you have to go over a few more steps to put it back to Dynamics:
- Create a solution
- Add all the necessary components to that solution
- Export the solution
- Unzip the file
- Find “customizations.xml” file in the folder
- Modify XML in that file
- Then package everything into a new zip file
- And import that file into Dynamics
That’s quite a few steps not to mention that the file itself looks rather complex if you’ve never seen it before. For example, there are over 11000 lines in the customizations.xml for the TCS Tools solution:
So, manually updating that file must be unsupported, right? After all, we are supposed to configure Dynamics using the “customizations” interface. That’s what I used to be thinking (but that’s not to say that I would never update customizations.xml manually, though. Even if I felt somewhat guilty every time I’d be doing that). And that’s until I ran into this article just a few days ago:
As it turned out, it’s not just supported.. There is a bunch of tasks that you may want to do directly in the customizations.xml. Some of them can be done through the user interface, some of them can be done using the SDK. But, if you wish to, you can make those changes directly in the customizations.xml:
- Editing the ribbon
- Editing the SiteMap
- Editing FormXml
- Editing saved queries
Actually, if you look at those 4 items, it kind of makes sense.
There are no SDK methods which you can use to update the Ribbon, yet you cannot do much about the Ribbon in the user interface. Of course there is Ribbon Workbench, but what it’s actually doing exactly that – it’s updating customizations.xml.
There are no SDK methods which would allow us to update FormXml either. More exactly, we can use SDK to update form records.. but we still have to use XML there. Or, alternatively, we can update customizations.xml, package the solution, and import it to Dynamics.
As for the save queries, that’s, probably, even more interesting. When building those queries in the user interface, we have to accept some limitations such as:
- Can’t use distinct=false
- Can’t use left-outer joins
- Can’t link the same entity more than one
However, since FetchXml has support for all those feature (and it’s only a user-interface limitation that we can’t use them), we can still update those queries directly in the customizations.xml and import those changes to Dynamics.
This is not necessarily a game-changer, but it definitely makes me feel better keeping in mind that there is, probably, not a single Dynamics implementation where I would not make at least one of those changes in the customizations.xml (even if only to add a ribbon button using Ribbon Workbench)