I assumed that for an Update plugin, it specified a list of attributes, that if are changed, cause the plugin to fire.
So if I register a plugin against Foo
, with only one filtering attribute specified against Bar
, every time a Foo
entity is updated, CRM performs a check to see if Bar
has been updated, if it has, it runs my plugin. So with the code below, I would expect my plugin to execute once.
Foo foo = new Foo();
foo.Bar = 0;
foo.Id = service.Create(foo);
foo.Bar = 1;
service.Update(foo.Bar); // My plugin would execute
service.Update(foo.Bar); // Bar hasn't changed, I would assume the plugin will not execute
Am I right in this assumption?
In order to prevent extra processing in the environment, minimize the logic needed in a plug-in and all the update to complete as quickly as possible, it is highly recommended that plug-in step registrations also include filtering attributes for update messages.
If no filtering attributes are set for a plug-in registration step, then the plug-in will execute every time an update message occurs for that event. A combination of no filtering attributes and auto-save functionality could lead to unnecessary plug-in executions causing undesirable behavior and degrade performance.
The CRM ui doesn't usually send a value unless it has changed (forcesubmit overrides this behaviour). In your example Daryl the plugin will fire twice as the filtering attribute is present in both requests. Show activity on this post.
If you use “Filtering Attributes” on post update events, you don’t need to compare the value of fields using PreEntityImage and PostEntityImage. The other biggest advantage is that your plugin does not execute on every update event. Here is some code. This code creates a note for a contact when parentcustomerid field is updated.
While your initial analysis is loosely correct (i.e. filtering attributes cause the plugin to fire only if one or more filtering attributes have changed) this is not fully accurate.
When an entity is changed, e.g. the email address on a contact, the platform (and therefore your plugin) only receives the delta. In my example there would be an Entity in the Target
InputParameter which only contains a single attribute (email
). This is the case even if the contact record contains much more data - only that which is changed is sent to the platform. (as an aside, this is where Pre and Post entity Images come in as they allow you to access values on the entity that weren't changed, without having to issue a Retrieve).
So with this in mind it is instead correct to say that filtering attributes mean that the plugin will only fire if one or more of the filtering attributes are present in the request. The CRM ui doesn't usually send a value unless it has changed (forcesubmit overrides this behaviour). In your example Daryl the plugin will fire twice as the filtering attribute is present in both requests.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With