Check your plugin code, or here is what you’ll see: There should be only one owner party for an activity

By | April 13, 2017

There is an interesting error I’ve never seen before that can now happen in Dynamics whenever you are deleting a service activity:

Log file does not have a lot of information, but there is a clue:

[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[75200d82-9f20-e711-8118-480fcff4b171: ]
Starting sync workflow ‘Assign SA’, Id: 6f200d82-9f20-e711-8118-480fcff4b171
Entering AssignStep1_step:
Sync workflow ‘Assign SA’ terminated with error ‘There should be only one owner party for an activity’

</TraceText>
</InnerFault>
<OriginalException i:nil=”true” />
<TraceText i:nil=”true” />
</OrganizationServiceFault>

The workflow mentioned above is extremely simple:

You see, the workflow is simply reassigning a case to another user when the service activity is being deleted.

You may ask why would I need such a workflow.. Can’t think of any particular reason, but it’s a simplified test for a more complicated scenario which I will describe below. For now, let’s just summarize what’s happening there:

  • We are trying to delete a service activity
  • That starts a workflow
  • That workflow is re-assigning a “regarding” case to another user
  • And, then, an error occurs

I cannot explain why would this error happen, though I’m assuming Dynamics is trying to do something behind the scene and it can’t because, maybe, that SA record is locked in the “delete” transaction?

Either way, the end result is, we are seeing a rather confusing error message: “There should be only one owner party for an activity”

Here is a real-life scenario, though:

  • Imagine there is an on-delete plugin that recalculates duration fields on the account/case whenever a service activity is being deleted
  • Imagine that plugin is retrieving case record, modifying duration field, and, then, just pushing it all back

This is not the right technique – we should not be pushing all attributes back, but it happens sometimes. The end result is that the “owner” attribute of the case entity is pushed back as well.

Now, we know that “AssignRequest” has been deprecated by Microsoft, and we are now supposed to just update the “OwnerId” field directly:

https://msdn.microsoft.com/en-us/library/dn932124.aspx

However, it seems we are also not supposed to update it when we don’t need to:) In the above example, that’s exactly what’s happening though, and, it seems, it can lead to exactly the same error as it happened here:

https://community.dynamics.com/crm/f/117/p/233501/639084

 

 

 

Leave a Reply

Your email address will not be published.