UpdateRequest vs SetStateDynamicEntity

By | May 6, 2019

 

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:

image

The plugin has been registered on the Update of the new_test entity:

image

When trying to deactivate a record manually, I’m getting the error as expected:

image

However, when using a workflow:

image

Which, by the way, is set up like this:

image

The plugin does not kick in and the record gets deactivated:

image

Registering an additional step for the same plugin on the SetStateDynamicEntity message does help, thouhg:

image

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:

https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2016/developers-guide/gg308277(v%3Dcrm.8)

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.

Leave a Reply

Your email address will not be published. Required fields are marked *