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?
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
TargetInputParameter 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.