Dynamics 365 CRM has the ability to run your own custom C# code on certain CRM entity events, known as plugins. You can set up a plugin to execute on record creation, update, and deletion. For example you can setup a plugin to execute your code whenever an Account is created. This functionality allows us to build our own features that aren’t available out of the box, vastly expanding the capability of CRM.

Inside of a plugin, we are able to create, update, or delete other CRM records. We could also connect to a separate data source, check or update some values, and reflect those changes back in CRM. With plugins we could append to a spreadsheet in OneDrive, send email notifications, update or create items in Sharepoint… There are tons of possibilities here – basically anything that can be run in code, can be run in a plugin.

As stated before, plugins are executed on CRM entity events. The screenshot here shows an example of an Account Create plugin setup using the Plugin Registration Tool. This tool allows us to apply and manage plugins in CRM instances. For Update events in CRM, we have the ability to filter when the plugin executes when specific fields are updated (see “Filtering Attributes”). For example, we could execute an Update plugin for Accounts only when the Email field changes. Delete events are also available to run after, useful for cleaning up advanced relationships or child records.

CRM plugins also have the ability to be asynchronous – meaning it can be set up to run in the background, and thus running in the background later, this allows the save to complete before this extra work is done which means the user is not forced to wait for it to complete. This can help the user interface be more responsive. Normally if the plugin is not asynchronous (or “synchronous”), the user will have to wait until the plugin is done executing before interacting with CRM. This means if you have a plugin on Account create, it will start executing when you click Save and the UI will be unavailable until all plugin work is complete. A plugin being synchronous is sometimes necessary – going back to the Account creation example, maybe you need values to be set, and you want those values populated for the user to continue working with the Account. If it runs asynchronously, those updates won’t be seen on the form immediately, and user data could potentially make updates to the fields that will later get worked on by the plugin. This can cause problems where fields get overwritten based on whether the user or plugin runs first/last!

There are some tradeoffs when choosing between asynchronous and synchronous plugins, and I would like to share an example I went through recently.

We have a client that uses plugins to create a set of Sharepoint folders on when specific records are created. We had originally set these up to be synchronous so we could ensure that all folders have been created and the documents area in CRM was set up. Inside the plugin, we have some code that creates the Sharepoint folders which could take multiple seconds to complete. The problem is if the folders and CRM were not ready by the time the user gets to the Documents area, they will see an error. However, we recently changed these plugins to be asynchronous for two reasons; One because it is a rare use-case that the user goes directly to the Documents area upon record creation, and because they valued performance more than this safety feature. We cut entity create load times by nearly 80% by simply switching the plugins to asynchronous!

This is just a brief introduction to what CRM plugins can do, as well as the trade-offs of asynchronous vs synchronous. Be sure to contact us at the Velosio Grand Rapids office for your CRM plugin needs!