This statement holds true whether you are updating attributes through the SDK dlls or over web services. It doesn’t matter whether you’re coding for a plugin, workflow assembly, Silverlight app or some external custom application like a windows application or web application. The potential outcome in all the scenarios will be the same! What’s the outcome? Triggering other automation unwantedly!
When designing a system you will find that automation solves a lot of problems! But you may only want the automation to occur in a particular situation so, you take great care in dictating when your automation should occur… I hope! For workflows you set them to run only when a specific field changes. For plugins you ask your developers to set the filter so that the plugin only fires when a field changes. Feel like your automation is safe from incorrectly firing? You have taken great care in narrowing down your triggers so it should be… Well sorry to say its not!
Say hello to Sebastian, he doesn’t know it but he’s a cowboy coder. He’s not fully aware of any of the execution pipelines in CRM, but knows how to retrieve data, manipulate it and save it back to CRM through the SDK. Sebastian has been tasked to work on some of your more complicated automation on an entity that you have set up workflows against. Part of Sebastian ‘s automation requires him to retrieve a certain field, alter it and save it back to CRM. None of your workflows are set to fire on this field, however after Sebastian has deployed his automation you find your workflows are constantly firing every time his automation executes! WHY??? Well Sebastian has lived up to his cowboy name. What he has done is retrieved all of the record’s fields, changed the one he needed and then called update on the record… which contains all the fields… which CRM thinks you are updating… which triggers your workflow. BAD SEBASTIAN!
So coders, when we are asking the CRMService to update our records, put down that cowboy hat, and make sure that our object only includes the attributes we want to update. CRM won’t work out what has changed for you, you have to do it yourself! If you are building your object up from the ground then the chances are you are doing this already. If you have retrieved some data and are updating it, think about what I have said and remove unwanted attributes, or don’t retrieve them in the first place.
Invisible Resource Hog
In my example the effect of updating everything was visual. However, incorrectly updating everything could be triggering automation who results aren’t visual. This means that your CRM system will be consuming more resources than it needs to. The reason being…
So if your system seems to be a bit sluggish, and you know you have a lot of automation don’t rule this out!