When creating Microsoft Dynamics CRM, Microsoft realized something very important, the system will need to be customized by partners to fully fit the needs of the customers. However, customizations need to be upgradable and support update rollups and hotfixes. Previously, all upgrades would require rather large efforts in re-writing lot of the code that was custom built for the customer. However, the definition of supported and unsupported customizations and the promise from Microsoft that all supported customizations will be upgradable and updatable at least to the next version, is something that is very good and will ensure a better return of investment of the custom development made for customer and also improve partner-customer relations since paying for upgrades of already made customizations seldom improves the partner-customer relationship.
We have worked with many systems where other consultants and developers have created solutions and here are some of the more common unsupported customizations, why they will cause problems and alterntive solutions:
HTML DOM addressing and modifications
This is very common i CRM 4.0 but is also quite common in CRM 2011. The problem with this unsupported customization is that when upgrading the system the names of the elements in the HTML DOM will probably change. This is obvious in the case of isv button addressing in CRM 4.0 since the ribbon HTML DOM element names are different. The code will hence break after an upgrade.
Modifications to the CRM database are also some of the more common unsupported customizations that I have experienced. It can be anything from custom views to new stored procedures or even modifications to the existing procedures. Do note that creating indexes in the database is supported but not upgradable.
Developers making these kinds of customizations usually do not realize the effects that they have and might be used to and very familiar with writing T-SQL. Modifications to the existing tables and views are very hazardous since CRM is a metadata driven application meaning that the database contains metainformation on how the database looks. If the metainformation gets out of sync with the real database, you will have a very nasty problem on your hands.
Additions to the database, without any modifications, will usually work with updates to the system. However, when upgrading or redeploying the system these usually cause quite a lot of problems. It is also a general recommendation to try to keep all business logic in the same layer of the application and to not mix them between the database and higher layers (like plugins). This can sometimes not be avoided however.
So, if you do need to create some custom views or similar, create a database next to the CRM database with hosts these and use cross database addressing to work with the data.
Modifications to CRM files or additions to the CRM installation directory
The reason these customizations should be avoided is that any update rollup that is installed might overwrite these files and you customization might be lost. With upgrades the customization will most certainly be lost or stop working.
Unsupported customizations are necessary anyway
If the requirement still demands unsupported customizations, and there is no good way around it, I recommned having a discussion with the customer on the effects of creating unsupported customizations in regards to upgrades and increased maintainance costs. If the still feel it is required, I recommend you getting their formal signature on a document describing it as an unsupported customzation and that the customer understands that the function might not be upgradable and that upgradecosts will be fully charged to the customer. It might feel a bit formal, but trust me, when the customer wants to upgrade, you will be happy you have the document.
Another important aspect that you need to remember when creating unsupported customizations, is that you need to take this fact into account. For instance, if addressing an HTML DOM element, make sure to handle the fact that it might not exist, and have some resonable fallback from this.
It is also essential to document each unsupported customization with extra care. I recommend a special document for this. It should include some of the following topics:
- Description of requirement
- Technical desciption of the solution
- Why it has to be made with unsupported customizations - This is important as newer versions of CRM might enable you to rewrite this in a supported manner.
- Possible effects on an installation of an update rollup -
- Possible effects after an upgrade
- Checklist to verify the functionality.
CEO, Chief Architect and co-Founder at CRM-konsulterna AB