Dynamics 365 customisation is one of those topics where everyone has an opinion and most of those opinions are wrong. The Microsoft partner ecosystem is full of firms who will happily build you a cathedral of custom plugins and JavaScript web resources when a few business rules and a Power Automate flow would have done the job. And on the other side, you get the "no code" evangelists who insist everything can be done with configuration, right up until the moment it cannot and the whole thing collapses.
The truth, as usual, is somewhere in the middle. After years of working as a Dynamics 365 Technical Architect, I have developed a fairly straightforward way of thinking about this. It is not complicated, but getting it wrong is expensive.
Configuration first is not just a slogan
Microsoft built Dynamics 365 to be configured, not coded. That sounds obvious, but you would be amazed how many implementation teams skip straight to writing C# plugins for things the platform already handles out of the box. I have inherited projects where someone wrote a custom plugin to do field validation that could have been a single business rule. No code to maintain, no deployment pipeline, no unit tests needed. Just a rule that works.
The reason configuration should always be your first instinct is upgradability. Every time Microsoft pushes a platform update, your configuration travels with it. Your custom code might not. I have seen organisations stuck on outdated versions of Dynamics because their custom plugins had dependencies on internal APIs that Microsoft changed. That is not a theoretical risk. That is a Tuesday.
So before you write a single line of code, ask yourself three questions. Can a business rule do this? Can a workflow or Power Automate flow do this? Can a calculated or rollup field do this? If the answer to any of those is yes, stop there. You are done.
Where configuration runs out of road
That said, there are plenty of scenarios where configuration genuinely cannot do what you need. Recognising these quickly saves everyone time and frustration.
Complex cross entity validation is a classic example. Business rules work brilliantly for single entity field validation, but the moment you need to check something against a related record, or validate across multiple entities in a transaction, you need a plugin. There is no configuration workaround that does this reliably.
External integrations are another obvious one. If you need to call a third party API during a save operation, or push data to an external system in real time, you are writing code. Power Automate can handle some of this, but for anything that needs to run synchronously within the transaction pipeline, a plugin is the right tool. I wrote about integration patterns that actually work in production in more detail if you want the full picture.
Performance sensitive operations also tend to need code. If you are processing thousands of records, doing complex calculations, or need precise control over execution order, configuration tools will either be too slow or too unpredictable. A well written plugin that runs server side will outperform a Power Automate flow by orders of magnitude in these scenarios.
The danger zone: JavaScript web resources
If I had to pick the single biggest source of Dynamics 365 implementation pain, it would be JavaScript web resources. They are necessary sometimes. They are overused almost always.
JavaScript in Dynamics 365 runs on the form, which means it only runs when someone opens that form in a browser. It does not run on imports, it does not run on API calls, it does not run on mobile unless you are very careful about how you write it. I have lost count of the number of times I have been called in to fix a system where critical business logic lived entirely in form JavaScript, and then someone imported 10,000 records via the data import wizard and bypassed all of it.
Use JavaScript for user experience enhancements. Show or hide sections. Filter lookups. Display a warning message. That is what it is good at. The moment you find yourself putting business logic in JavaScript, stop and move it to a plugin or a business rule instead. Your future self will thank you.
Power Automate: the middle ground that keeps growing
Power Automate has changed the equation significantly. Five years ago, if configuration could not do it, your only option was C# plugins. Now there is a genuine middle ground that handles maybe sixty to seventy percent of the cases that used to require custom code.
It is particularly good for asynchronous processes. Sending notifications, creating follow up records, calling external APIs where you do not need an immediate response, syncing data to other systems on a schedule. All of these used to require custom code and deployment pipelines and all the overhead that comes with that. Now a business analyst can build them in a browser.
But Power Automate has limits that people hit faster than they expect. Error handling is clunky. Complex branching logic gets unreadable quickly. Performance degrades with large data sets. And the licensing model means costs can spiral if you are not careful about premium connectors and flow runs.
My rule of thumb: if the flow has more than fifteen steps or more than three levels of branching, it probably should have been a plugin. Debugging a massive Power Automate flow is genuinely worse than debugging code, because at least with code you have proper logging, source control, and the ability to step through it.
A decision framework that actually works
Here is how I approach the configure versus code decision on every Dynamics 365 project I work on. It is not revolutionary but it keeps things honest.
Start with the requirement and classify it. Is it data validation? Try business rules first, then plugins. Is it process automation? Try Power Automate first, then plugins. Is it UI behaviour? Try business rules or form configuration, then JavaScript as a last resort. Is it an integration? Evaluate Power Automate, then custom middleware, then plugins depending on whether it needs to be synchronous.
Next, think about who maintains it. This is the question that nobody asks and everyone should. If your client has a team of business analysts but no developers, building everything in plugins is a trap. They will not be able to change anything without calling you back. Conversely, if they have .NET developers on staff, a well documented plugin is easier for them to maintain than a sprawling Power Automate flow they have never seen before.
Finally, consider the upgrade path. Microsoft releases two major updates a year. Anything you build needs to survive those updates. Configuration survives automatically. Well written plugins using supported APIs survive with minimal effort. Unsupported customisations, direct SQL queries, and JavaScript that depends on internal DOM elements will break. Not if, when.
Real mistakes I have made
I am not writing this from some theoretical high ground. I have made most of these mistakes myself.
On one early project I built an entire approval workflow as a chain of custom plugins because I thought it would be more reliable than the built in workflow engine. It was more reliable. It was also completely unmaintainable. When the client wanted to add an extra approval step, what should have been a ten minute configuration change turned into a development cycle with testing, code review, and deployment. The client was not impressed, and they were right not to be.
On another project I went too far the other way. I insisted on doing everything with configuration and Power Automate, even when the requirements were screaming for custom code. The result was a tangle of flows triggering other flows, with race conditions and timeout errors that took weeks to untangle. Sometimes code really is the answer, and pretending otherwise just makes things worse.
The lesson from both of these is the same: be honest about what each tool is good at. Configuration is brilliant for standard business processes. Code is brilliant for complex logic and performance. Power Automate sits in between. None of them is the answer to everything, and treating any of them as a hammer turns every requirement into a nail.
Getting the balance right
If you are planning a Dynamics 365 implementation, or if you are stuck in the middle of one that feels harder than it should, the customisation question is worth revisiting. Look at what you have built. How much of it is configuration? How much is code? Could any of the code have been configuration? Could any of the failing configuration have been better served by code?
The best Dynamics 365 implementations I have seen use about seventy percent configuration, twenty percent Power Automate, and ten percent custom code. The worst ones invert that ratio. They are expensive to build, expensive to maintain, and they break every time Microsoft sneezes.
If you are not sure where your implementation sits on that spectrum, or you are about to start a project and want to get the balance right from day one, that is exactly the kind of thing I help with. Getting this decision right at the start saves an enormous amount of money and frustration down the line.
