Recently, I needed to write a Dynamics CRM plugin for CRM 2013 which, among other things, routed new leads to their owners via reassignment. The plugin navigated a logical labyrinth to determine the proper owner, assigned the new record thereto, and created an annotation for the new record. The plugin step was registered to fire against the Create SDK Message for the Lead entity, in the Post-Event stage.
private void AssignLead(Guid leadId, Guid newLeadOwnerId, IOrganizationService service)
{
AssignRequest assignLead = new AssignRequest
{
Assignee = new EntityReference(“systemuser”, newLeadOwnerId),
Target = new EntityReference(“lead”, leadId)
};
service.Execute(assignLead);
}
Once I worked out the kinks in the logic branching to determine the proper owner, I expected this to be a slam dunk. Instead, I was very surprised when the plugin kept throwing the following exception:
The log file provided additional details:
Since this looked and smelled like a security-related issue, I first pondered that possibility. However, I dismissed it almost immediately because the plugin step was already configured to run in the context of a CRM System Administrator, who would implicitly have full access rights.
Next, I donned my debugging cap and compared the new record's Guid against that shown in the error message. They matched precisely, which was confounding. However, during the course of this investigation, I was able to determine that the error occurred within the creation of the associated Annotation record. Based on that discover, I took a stab in the dark and moved the assignment to the very end of plugin logic. Presto... the error vanished!
When writing a Dynamics CRM plugin that involves a record assignment, always ensure the assignment is in the FINAL step in the plugin logic. I know I will be absolutely certain to do this in the future!
