Supported customizations
Part 11 of "11 things to know about customization"
Published: April 20, 2007
Microsoft 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 CRM addresses this in two ways:
1. | It provides most of the common customization capabilities within the metadata-driven customization tools. |
2. | It requires a degree of separation between your additional code-based customizations and the core application. |
On This Page
Metadata-driven customizations
As discussed in the first article of this series, Metadata-driven customizations, 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 defining your customizations is known, it is possible for the customizations that you have created to be upgraded without significant expense.
Separation of code
For more complex code-based customizations, extensions, and integrations, Microsoft CRM provides the client extension features described in Client extension features. You can also use Web service APIs that allow for integration to other systems or for custom automation in callouts or workflow assemblies. Because the signatures for these Web services are known, a new version of Microsoft CRM maintains backward compatibility.
Because this structure for creating customizations that are separated from the application exists, direct modification on the application is not supported. Any action that circumvents the design can introduce unknowns to the implementation. If the application code is changed, the Microsoft CRM Product team cannot take all the possible factors into account to provide the best upgrade experience. Because of this, the following actions are not supported.
| • | You should not modify the pages in the Web application. |
| • | You should not reference undocumented elements of Microsoft Dynamics CRM forms in form scripting. |
| • | You should not add tables directly to the database. |
| • | You should not directly update or add records to the database using SQL. |
Using supported methods
Notice that all these statements say “should not” instead of “cannot”. There is no mechanism in place to stop you from performing these actions. As someone customizing or supervising the customization of Microsoft CRM, it is your responsibility to enforce the use of supported customization methods.
There is almost always 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 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 CRM technical support.
