As per Microsoft the following is a list of common customization practices that are not supported in Dynamics CRM 2013.
- 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
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.
Pingback: Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM | Hosk's Dynamic CRM Blog
Pingback: Why you shouldn’t put unsupported customizations in Microsoft Dynamics CRM - Hosk's Dynamic CRM 2011 Blog - Microsoft Dynamics CRM - Microsoft Dynamics Community