I had a nice validation plugin that used to be working perfectly whenever a record were updated manually. When deactivating a record with a certain status reason, a user would see an error message if some of the conditions were not met.
For example, a transaction can’t be completed till the amount field has been filled in correctly.
Then I created a workflow which would apply the same status change automatically. The idea was that my plugin would still kick in, so all the validations would work. Surprisingly, it’s not exactly what has happened.
Whenever I tried using a workflow to change record status, my plugin just would not fire and the status would change.
Here is a version of the validation plugin that’s been stripped down of any validation functionality – it’s just expected to throw an error every time:
The plugin has been registered on the Update of the new_test entity:
When trying to deactivate a record manually, I’m getting the error as expected:
However, when using a workflow:
Which, by the way, is set up like this:
The plugin does not kick in and the record gets deactivated:
Registering an additional step for the same plugin on the SetStateDynamicEntity message does help, thouhg:
I am now getting correct “validation” error when trying to run my workflow as well.
So, it it seems, SetStateDynamicEntity request (and, possibly, SetState) is still being used internally, even though I used to think it’s been deprecated for a while now:
By the way.. While trying to come up with this simplified repro, I noticed that this may have something to do with the stage in which the plugin is registered. Everything seems to be working correctly in PostOperation, but not in PreValidation. And there are some quirks there, too. However, if you are trying to test your validations, and if you are observing this kind of behavior, it might help simply moving your plugin from PreValidation to PostOperation.
Of course the problem is that PreValidation is happening outside of the database transaction, so I can write some validation results back to Dynamics while in that stage, and it’s not possible in the Pre/Post Operation since all such change will be lost once an error is raised.. So, eventually, SetStateDynamicEntity might still be a better option.
I recently had a reason to code a process to deactivate a record to a custom statuscode and that following method can also be used.
https://docs.microsoft.com/en-us/dotnet/api/microsoft.xrm.tooling.connector.crmserviceclient.updatestateandstatusforentity?view=dynamics-xrmtooling-ce-9