- Plugins are hard to debug. One of the nightmares of CRM developers is to track an exception that happened inside a complex plugin – logging is limited and debugging is cumbersome or even impossible
- Plugins / Workflows time out. If you write complex logic in your plugin that has to read / insert / updates many records, you have no predictability about what will happen when your database will reach millions of records. It might happen that your plugin execution time will reach the timeout limit and re-engineering / optimizing your plugin would be a task that you’d want to avoid.
- Build your windows service. Encapsulate the complex CRM logic inside your windows service, add a lot of logging and make your code testable
- Expose the windows service functionality via a Web Api hosted inside your windows service
A slightly different version of the above is not to use a windows service, instead replace it with a classical WebService that would expose the complex logic. It is just a matter of preference. I find windows service approach slightly better, because I do not need to rely on IIS (making the architecture more flexible) as first note. As second note – usually when you have to deal with complex tasks in CRM, you might be asked to create different daily or import procedures, which normally would reside inside a windows service.
Please also note that the above apply only to CRM On Premise. If you have to deal with CRM Online, then you will need to adapt your architecture to Azure ecosystem. Things become more complex with CRM Online (because you will not be in the same network, as it is mostly the case with CRM On Premise) but for sure a similar solution can be found for CRM Online.