ColumnSet, Workflows and My Overstuffed Audit History
The following is the devil. You heard it here first.
Listen, I’m a lazy programmer. I accept this about myself. I get that it’s really easy to instantiate a new ColumnSet and pass in true so you get all the columns when you query CRM. You don’t have to worry about a lot of typing and you have everything there you need…
Life is perfect… until it comes time to Update the entity that you retrieved and you check your Audit History. See, the problem is when you pull back all of the columns in an Entity and then call Update, Microsoft CRM isn’t smart enough to know which values changed and which ones didn’t. So if you pull back every column and call Update, CRM records that every column got updated. Even if you only changed (or added) a single value.
That’s not exactly ideal.
Why is updating every column bad?
The problem is that in a lot of cases, there will be Workflows that trigger when a field is updated (especially a system field.) So, lo and behold, when you update your Entity with all of its data, you suddenly find that one (or more) workflows get fired off that have no business firing. Even if you’re smart and you have check conditions in your Workflows that prevent the Workflow from firing (and say emailing the CEO), you’ve still bogged down your server and added extraneous, meaningless data to your database. That’s bad. Especially because you have to go back and now rewrite and retest your code. Take it from me, fellow lazy programmer. You don’t want to do that. You want to list your columns out once like this:
And be done with it!
