Business Requirement
I recently had a requirement where if an account's address was updated, all associated contact's addresses needed to be updated as well. Likewise, if a contact gets re-associated to another account, i.e. the parentcustomerid field gets changed, then update that contact's address.
Initial Development
I thought we could use a CRM custom workflow activity to handle this because it gives the business user the ability to configure the workflow. So I created two separate workflows that would call a custom workflow activity assembly. The trigger to call the account workflow was if any of the address attributes changed, and for contact was if the parentcustomerid was set/changed.
The assembly itself first checked the workflow context to see what the primary entity was (to handle being called from the account or contact workflow). Then the required business logic was performed, and the CRM web service update was called to update the contact entity.
Test Results
After I registered the assembly and started unit testing, it looked as if everything worked. Then looking at the history of workflows for the test contact record, I noticed about six entries for the workflow I just configured. Then I used a VPC and tested the assembly by using Visual Studio debugger, attaching it to the CRM Asynchronous Service process, and found that there was an infinite loop occurring.
When the contact record was re-associated to another account, the workflow kicked off and executed the custom assembly. Within the code, it set only the address properties on that record and then called the CRM service update method. Right after that update was made, a new workflow instance was called again. To make sure, I commented out the update call in the code and…no more loops!
Final Thoughts
Some technologies have flags for attributes to determine if that particular attribute has been updated or not. When the CRM web service update was called, even though I only set the address fields, it seems to "flag" that all attributes have been updated. Either that, or the workflow conditions were never checked.
I even tried to add some sort of check to make sure even if the workflow was called the code wasn't executed. However, unlike plug-ins, workflows don't have functionality to check the values before and after an update. I also tried putting a global counter to update after the first run, and check if the method was called again. However, the entire workflow was called again, which created another instance of the class, thus the counter idea didn't work.
Solution
I finally ended up using a plug-in, which you can configure to run asynchronously if you heart desires. In the future, I now know that a workflow should not be setup to call a custom assembly that updates that same record. The CRM web service update will cause infinite loops, and is better handled via a plug-in.
