Common unsupported customization practices in Dynamics CRM 2013

As per Microsoft the following is a list of common customization practices that are not supported in Dynamics CRM 2013.

• Interacting with the web application Document Object Model (DOM) elements using JavaScript
• Using any undocumented internal objects or methods using JavaScript
• Directly changing files in the application
• Retrieving data directly from database tables
• Updating data directly in the database tables
• Changing the database tables, stored procedures, or views

Interacting with the web application Document Object Model (DOM) elements using JavaScript:  Any JavaScript libraries used anywhere in the application must only interact with the documented APIs. When JavaScript developers work with applications they frequently access DOM elements using specific names. Because Microsoft Dynamics CRM is a web application these techniques work, but they are likely to break during an update rollup or upgrade because the names of the elements they reference are subject to change at any time. We reserve the right to make any changes necessary in the application and this frequently means changing how the page is constructed. Adding any changes that depend on the current structure of the page means that you will need to invest in testing and perhaps changing the custom code in these scripts each time you apply an update rollup or upgrade your application.

JQuery is a very common library used by JavaScript developers. Most of the benefit of using JQuery is that it simplifies a developer’s ability to access and create DOM elements, which is exactly what we do not support in the CRM application pages. JQuery is recommended when developers are creating custom user interfaces with HTML web resources, but within the CRM application pages, the supported APIs do not require JQuery to be used.

Using any undocumented internal objects or methods using JavaScript: Microsoft Dynamics CRM uses many JavaScript objects within pages. A JavaScript developer can discover these objects by debugging a page and then access and reuse these objects. We reserve the right to make any changes necessary to these objects, including removing them or changing the names of the methods. If a script references these objects the script will break if they are not found.

Directly changing files in the application: If you have Microsoft Dynamics CRM 2013 on-premises you have access to the web application installed on your server. The web application contains many text files that a developer could edit or replace to change the behavior or appearance of the application. Changing these files is not supported because any update rollup that you install could remove your changes and the files will be overwritten when you upgrade to the next release.

Retrieving data directly from database tables: If you have Microsoft Dynamics CRM 2013 on-premises you have access to the database so that you could retrieve data directly from the tables. However, by doing this you are by-passing the security infrastructure. The recommended practice is to use special filtered views to retrieve the data. This will apply the calling user’s security so that they can only see data that they should see.

Updating data directly in the database tables: If you have Microsoft Dynamics CRM 2013 on-premises you can perform updates on the CRM data directly in the database tables. The risk with this approach is that you can set invalid data that can break the application. Developers should always use the APIs provided with the application platform web services to update data.

Changing the database tables, stored procedures, or views: If you have Microsoft Dynamics CRM 2013 on-premises you can use database tools to change the database. The only direct database changes that are supported are adding or updating indexes as described in Custom SQL Server indexes. You should use the customization tools to add any new entities or entity attributes. This is the only supported way to apply changes to these parts of the database. Any direct changes you make risk breaking the application or your ability to apply update rollups. Any changes you apply may be destroyed when you apply an update or during an upgrade and any data that you may have included in custom database table columns will be lost.

Advertisement