Published Date : January 1, 2008
Microsoft Dynamics CRM is designed to avoid some of the common problems found in highly customizable business applications. One common problem is that people will customize their systems to such an extent that they cannot upgrade – they paint themselves into a corner. Microsoft Dynamics CRM addresses this in two ways:
It provides most of the common customization capabilities with the metadata-driven customization tools.
It requires a degree of separation between your additional code-based customizations and the core application.
|
|
Metadata-driven customizations |
|
|
Separation of code |
|
|
Using supported methods |
As discussed in the first article of this series, Part 1: Customization advantages, the customizations that you can configure in the application are stored as metadata without changing the core part of the application. Because the structure of the metadata that defines your customizations is known, it is possible for the customizations that you have created to be upgraded.
For more complex code-based customizations and extensions, Microsoft Dynamics CRM provides the client extension features described in Part 9: Client extension features and Web services that allow integration with other systems, or for custom automation in plugins or workflows.
Because of this structure for creating customizations, which are separated from the application, direct modification of the application is not supported. Any action that circumvents the design can introduce unknowns to the implementation. If you change the application in an unsupported way, the upgrade process cannot take all the possible factors into account for the best upgrade experience. Therefore, some types of customizations are not supported. The full list of unsupported customizations is listed in the Microsoft Dynamics CRM SDK. This list summarizes some common customization approaches that are not supported:
You should not modify the pages in the Web application, except any files you add to the ISV folder.
You should not make any changes to the file and Web site settings of the Microsoft Dynamics CRM Web site.
You should not make any direct changes to the database.
You should not reference undocumented elements of Microsoft Dynamics CRM forms in form scripting.
You should not reuse any available Microsoft Dynamics CRM installed JavaScript code. This code may change or be overwritten during an upgrade.
You should not directly update or add records to the database using a direct SQL Server connection.
Notice that all these statements say “should not” instead of “cannot”. There is no mechanism to prevent you from performing these actions. As someone customizing or supervising the customization of Microsoft Dynamics CRM, it is in your best interest to enforce the use of supported customization methods.
There is usually a supported way to achieve your goal without resorting to unsupported customizations. This might not always be the method that seems the most direct to a developer who hasn't worked with Microsoft Dynamics CRM before, but creating a supported solution will pay off in the long run.
In the event that an unsupported customization strategy is used, you should always have a plan to be able to remove any unsupported customization or direct changes to the data and return to a supported state before upgrading or troubleshooting issues with Microsoft Dynamics CRM technical support.