I read an interesting CRM post today about how to get the new owner of a record in a plugin in CRM 4 and was interesting because the plugin uses a moniker instead of a dynamic entity
The blog post can be summarised by this qutoe
[Problem]
I have developed my plugin which is registered for Create and Update messages on the Account entity. The purpose of the plugin is to update internal ERP system.
Everything is working fine. But…
Problem 1: Update is triggered automatically when the user changes the owner of an account or in other words, when an account is reassigned. No clicking on ‘Save’ or ‘Save and close’ is necessary neither. Just changing the owner triggers the Update when page is being refreshed.
Problem 2: Owner change is still not reflected, so queries like <myaccount>.user_accounts as well as <myaccount>.ownerid always return the old owner.
[Solution]
After asking some colleagues and some research, I found out that I could register my plugin or another plugin (I chose the latter approach) to the Assign message.
The information in the blog post brought up a number of interesting questions. The fact that assigning entities doesn’t need you to save the record.
It’s also interesting you can trigger a plugin on an assign account, this is something useful to lock away for the future.
Another odd thing I found out recently is in CRM 4 certain context parameters are Monikers
Moniker entity = null; // what you get as Target in an Assign message is a moniker
if (context.InputParameters.Properties.Contains("Target") &&
context.InputParameters.Properties["Target"] is Moniker )
I didn’t know what a moniker was until recently, it isn’t used for update or create plugins but is used on Delete and assign and other plugins.
You can see what values a Moniker has here
This blog explains input and output parameters below is a line which I think explains what values a moniker has.
Target was of type -Microsoft.Crm.Sdk.Moniker having Id of the record to be deleted and name as lead
I then found this forum post which shows you how to test for a target
ou can test whether or not the InputParameters collection “contains” something, and you can also test an object’s type by using an “if” statement that uses the “is” keyword. A la:
if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is DynamicEntity)
{
// Work with the DynamicEntity
}
if (context.InputParameters.Contains("EntityMoniker") && context.InputParameters["EntityMoniker"] is Moniker)
{
// Work with the Moniker
}
You may be able to spool through the InputParameters, PreEntityImages, and PostEntityImages collections using this code (but I haven’t tested it, so your mileage may vary):
foreach (PropertyBagEntry property in context.InputParameters) {
if (property.Value is DynamicEntity) {
// The property is a DynamicEntity
// property.Name can be tested to evaluate as "Target"
}
else if (property.Value is Moniker) {
// The property is a Moniker
// property.Name can be tested to evaluate as "EntityMoniker"
}
}
I seemed to have gone off topic a bit here, the rest of the original blog post I was talking about basically returns the owner (SystemUser) class.
Hosk's Dynamic Blog 