Top 8 errors made by Dynamics CRM developers - Part 4 - No or invalid plugin filters

This is the fourth post in an 8 part series describing most common errors made by Dynamics CRM developers. It will cover:

Issue #4 - No or invalid plugin filters

Whenever you create a plugin on an update event an important decision to make is which attribute changes the plugin should fire on. It should be obvious that due to the cost of executing plugins running them should be avoided if we know beforehand that there will be nothing to do. 

If for example the logic of our plugin only depends on changes in Field1, there is no point in running it when Field2 value has changed. 

The trigger filtering is part of plugin step registration and can be most directly seen in the plugin registration tool. Off course some CRM developments frameworks allow this to be defined more high level (for example as part of a Visual Studio project), but the principle is the same.

Example of plugin registration:

In this example you can see that the plugin will only start executing when the owner of a Lead changes. Not only is this saving resources, by avoiding unnecessary executions of this code when other attributes of the Lead change. Even more importantly it immediately gives us a good idea of what the plugin is doing. If we also notice that it's executed post-operation, we can have good reasons to believe it updates other records based on the changing owner of the lead (good guess would be re-assigning them to other users). All this we can see just from the registration, without looking into the code. This is another reason, except performance, why correct trigger filters are a good habit. We need to remember CRM systems have a long life span and in a lot of cases will be taken over by other developers or even companies. Let's make each other's life easier.

Of course there are exceptions - like a plugin that does duplicate detection or auditing. But in the 99,99% remaining cases only attributes that actually cause a need for calculation should trigger the plugin step.

How to spot this?

Plugin update step executed on all attribute changes, with no apparent reason.