CRM Lesson Learned: be careful what you update...
So, I thought it would be nice to start a new series, "Lessons Learned". Well, I'm not sure it's gonna be more than one post, but it sounds nice right? :)
Anyway, todays lesson learned is "be careful what you update". I was recently working on a callout for recurring appointments, a much requested feature for MS CRM. In short, when an appointment was completed a new appointment was created based on some settings in the regarding account record. The regarding account record was then updated with last visit date.
However, on testing this callout I found out that every time the appointment was closed and a new one was created (through the callout), the owner of the two appointments changed. It was set to the owner of the regarding account record.
Now, the account entity has a parental relationship with the appointment entity. This means that e.g. a share or assign of the parent account is cascaded to the underlying appointment. That would explain the owner change of the appointments.
But I didn't do any assign or anything that would trigger the cascading rules, I only updated a custom datetime field, or so I thought...
I searched through my code to see if I assigned anything to the ownerid of the account record, but there was nothing. Finally, after some fruitless attempts I went to every line of my code to see what could be wrong and then it struck me. I retrieved the parent account and the columnset contained the accountid, cwr_lastvisitdate and the ownerid! I needed the ownerid for a check.
After I retrieved the account I only updated the cwr_lastvisitdate field and then I called crmservice.Update() on it.
However, when you call Update on an entity it updates all the fields contained in the entity. And the entity also contained the ownerid! And apparently, because the ownerid was updated (even though it was not changed!), MS CRM interpreted it as an Assign. The rest is history. The assign triggered the cascading rules and the owner of all underlying records was changed to the owner of the account.
So the lesson learned: be very careful about which columns you retrieve when you want to update the retrieved entity. You might get some unexpected results :)
Happy coding and stay mobile!
Anyway, todays lesson learned is "be careful what you update". I was recently working on a callout for recurring appointments, a much requested feature for MS CRM. In short, when an appointment was completed a new appointment was created based on some settings in the regarding account record. The regarding account record was then updated with last visit date.
However, on testing this callout I found out that every time the appointment was closed and a new one was created (through the callout), the owner of the two appointments changed. It was set to the owner of the regarding account record.
Now, the account entity has a parental relationship with the appointment entity. This means that e.g. a share or assign of the parent account is cascaded to the underlying appointment. That would explain the owner change of the appointments.
But I didn't do any assign or anything that would trigger the cascading rules, I only updated a custom datetime field, or so I thought...
I searched through my code to see if I assigned anything to the ownerid of the account record, but there was nothing. Finally, after some fruitless attempts I went to every line of my code to see what could be wrong and then it struck me. I retrieved the parent account and the columnset contained the accountid, cwr_lastvisitdate and the ownerid! I needed the ownerid for a check.
After I retrieved the account I only updated the cwr_lastvisitdate field and then I called crmservice.Update() on it.
However, when you call Update on an entity it updates all the fields contained in the entity. And the entity also contained the ownerid! And apparently, because the ownerid was updated (even though it was not changed!), MS CRM interpreted it as an Assign. The rest is history. The assign triggered the cascading rules and the owner of all underlying records was changed to the owner of the account.
So the lesson learned: be very careful about which columns you retrieve when you want to update the retrieved entity. You might get some unexpected results :)
Happy coding and stay mobile!
posted by Jeffry @ CWR Mobility at
11:36
0 Comments:
Een reactie plaatsen
Links to this post:
Een koppeling maken
<< Home