Republished from Dynamics University
When embarking upon the path of modifying your Microsoft Dynamics CRM environment, there are an endless supply of resources. Many of them are great resources while others are certainly a Pandora’s Box…or perhaps you might even say a Hydra. What do I mean? Well, some resources and advice you run across that provides you a slick solution to a customization challenge may provide.
a short term fix, but in reality open you up to a whole series of potential issues down the road and perhaps lock you into a solution that you cannot escape from. One of the sources of these issues is with unsupported customizations. Many of you may have even heard a consultant tell you, “That is unsupported” or “I could do it but it may be unsupported.” I know I have told customers that! Often, however, this is met with a befuddled look as to what does “unsupported” actually mean and more importantly, what kinds of things are unsupported. Let’s take a look.
To begin, let’s define what the term unsupported means as it relates to Microsoft Dynamics CRM customizations. If something is deemed “unsupported” it is the kind of customization that if encountered by a support engineer at Microsoft or if you contact them looking for help with an unsupported customization, they won’t help you. Why? Isn’t that what they are supposed to do? Help me? Let’s look at why they give some customizations this moniker:
- Some customizations you are able to do (particularly customizations done via code) can lead to your environment being un-upgradable or at least difficult to upgrade.
- At times, Microsoft will change particular pieces of their code that are innocuous to the end user but customizers/developers may leverage for their own purposes. If MS changes these elements, it can potentially cause custom code to break.
- Some customizations involve you changing base files within your deployment (i.e.: .ASPX, .XSLT, .CSS, and so on). These files can change and thus causing a customizer’s/developer’s changes to disappear.
- Because Microsoft Dynamics CRM is a web application, there are far, far too many possible things that a developer who is savvy with JScript (as an example) can do to really make a mess of a deployment. As such, it is not realistic for MS to support and help all people who want to do crazy stuff with their deployments.
Keep in mind that beyond their ability to actually help and support you, part of their job is to ensure the brand proposition of the product. For example, if you read the phrase “All of your customizations are upgradable” in any MS marketing literature related to Microsoft Dynamics CRM, they need to be able to back that up! So, if they are asked to support every JScript that makes the user’s screen shake, blink, and change all the forms to lovely shades of purple and pink, they would not be helping folks with real issues and they may be helping you do something that will not work after your upgrade. If they did that, they would be failing to deliver on that brand proposition.
So, what are some examples of unsupported customizations? You’ll find a few examples below:
- Modifying any of the .aspx, .css, .htm, .js, .xml, .jpg, or .gif files found in the installation directories of your deployment.
- Direct modification of the Microsoft Dynamics CRM database schema. This includes adding columns to tables, modifying any CRM related stored procedures, or modifying the CRM views.
- Direct updates to SQL tables in way other than outlined in the CRM SDK.
There is a relatively lengthy list of “things” considered to be unsupported. For a more detailed list, go to http://msdn.microsoft.com/en-us/library/gg328350.aspx#Unsupported
To be 100% fair, there are times when I have done some of the dubious unsupported customizations. There are simply times when there is not an alternative (well I suppose there is always an alternative…such as not doing the project or not doing the customization). That being said, if you find yourself in this sort of conundrum, here is my advice:
- Ensure that there is not a supported alternative. For example third party products or another development approach that is actually supported.
- If you absolutely must do it or the customer insists, be sure that they understand the potential risks. Put it in writing and make sure they acknowledge the risks. There are some things that are considered unsupported that are very quick and very simple to do that pose little risk, while others pose a significant risk of recoding after the next upgrade or even an un-upgradable system unless the changes are removed. Additionally, MS support will sometimes not help a customer once they find that the issue is related to an unsupported customization. Truth be told, you may get a sympathetic soul who will guide you through the unraveling of your unsupported customization debacle, but many support folks will 100% toe the line on this and not help you.
- TEST, TEST, TEST…..and then TEST it again to ensure that it not only works, but does not break other existing functionality in CRM.
- Back up and document the customizations.
There are likely other considerations, but these (in my humble opinion) are a good starting point for your consideration. Oh, and by the way, there are a TON of supported customizations you can do in CRM 2011 that you were never able to do in earlier versions. For a guide on this, go to http://msdn.microsoft.com/en-us/library/gg328350.aspx.