Working with Plugins (or not!)

Let's face it, plugins are difficult to develop today in Dynamics. But you must use them for some things, but not everything. With flow and webhooks, it is fairly obvious that MS is inviting you to take functionality that was previously put into plugins, and place them into external, narrowly scoped services.

Yes, plugins are essentially a callback interface to events that occur, which is not totally bad. And "callbacks" is much like the ability to use the Azure bus (limited in "choice" scope but very useful) which is dramatically better in many ways despite buses always being a bit harder to use. Plugins, however, have limitations due to governors, such as runtime length restrictions, they have a constrained API surface you can use, are hard to develop for and generally have to be loaded into the Dynamics system to run along with at least a decade old registration step process. While there are helpers in Visual Studio for this, it's still time consuming and less than ideal.

It's also quite an older style of composing applications although it still works and has some advantages. But is quite difficult development lifecycle wise to develop, debug and manage. A microservice model makes alot of sense. I guess you can think of an event handler as a microservice and that's fine, but it's still hard and you have limited choices for a some development and production concerns.

Of course, MS knows this and encourages you to use services from Azure or anything else that makes sense. You can even think of the data virtualization features present in the July 2017 release (virtual entities) as a way to start thinking more flexibly about data integration and processing. These new capabilities make it easy (e.g. webhooks) to develop off-platform solutions. Of course, taking everything off platform does not make sense and so you still need to develop plugins, although and hopefully, with narrow scope.

See the next section about scripting.