When writing code with 365 – especially JavaScript within the application – it’s easy to become unsupported if you’re not careful, or otherwise unfamiliar with the application. Staying supported means, you can assume (with reasonable confidence) that your implementations will;
This article is part of a series
When working with Dynamics it’s always worth remembering that you are working inside someone else’s application – this isn’t your house, you don’t get to set the rules. You have a product that you can customise, configure, and extend – but not fundamentally change. You want to work with the product, not against it. Microsoft provide a set of tools and guidelines describing the things we can do, they also tell us the – unsupported – things we shouldn’t do. It’s all on the MSDN. Un-supported scenarios that commonly occur:
When you go un-supported you are working against the system. Whilst you may be able to deliver functioning un-supported customisations, you will probably find it was harder to deliver, an upgrade is more likely to break them, and Microsoft support maybe less helpful (i.e. asking you to remove unsupported customisations). Ultimately there is usually little benefit or need to go unsupported and I strongly recommended staying supported.
Original Post https://woodsworkblog.wordpress.com/2017/06/25/microsoft-dynamics-365-and-the-importance-of-staying-supported/