Dynamics365 (and it’s previous incarnations) is designed and built to be customized and integrated into your pre-existing Line of Business applications and/or seamlessly integrate into your new ones.
That’s the goal of the platform (in my humble opinion).
To this extent, the only times you should be afraid of performing customizations on the core or extended system are;
- You don’t understand the requirements and are changing things willy, nilly all over the place.
- You have gone beyond writing your own code and are now changing underlying code which may or may not be supported in future upgrades.
- You are recreating functionality that already exists in the system in your own variant.
- You are taking something called an account and making it look like a “cat” but then having to create another thing called an “account” because you messed up the initial account.
Those are times when customizations in Dynamics can get you into a world of hurt.
Now, think about your work as a C# developer, Java, Web, VB.NET, Python, PHP, whatever and read those 4 items again.
That’s right, those 4 tenets apply to any software development language or platform not ONLY Dynamics365.
I think the “problem” (if you want to call it a problem with Dynamics) is that Customization and Solution Architecture is a very easy to get up and running with (good) but you can miss a lot if you don’t know what you are doing (bad). At the end of the day, don’t be afraid to customize and leverage core attributes, do be afraid when you are not leveraging functionality in the system and having to create your own.
It’s not good for you or your customers.