In our real world, unfortunately, didn’t work out that way. Or at least it hasn’t so far.
There’s a few corny things about Business Rules. First, they execute in the order you activate them. Excuse me, Microsoft, but that’s a bit of a bone-headed implementation. That means that developers would need to have a list of the correct order of activation just in case they needed to work with the rules. Why couldn’t they implement a relative sequence number is beyond my comprehension. Hey, they did it with USD window navigation rules!
Second, they need to be defined at the entity level to be executed on save. That means that now you have a process running all the time, every time, for every save you perform in that entity, regardless if you activate the validation only 5% of the time.
So what’s my final take on all this?
If you have a mostly vanilla CRM implementation, Business Rules might be the thing for you. This carries even more weight if you have Business Analysts putting in validations in your organization. No need to code these is a huge advantage.
However, if you have a highly-modified organization, with lots of heavy XRM, jQuery, and even DOM manipulation, your best bet is to stay away from Business Rules. In our implementation with the Unified Service Desk, where we have custom code for managing tabs in Save & Close, getting the Business Rules to work reliably has been a hair-pulling experience. The time you’ll spend spinning your wheels trying to get things working together is akin to herding cats: you might be able to pull it off, but in the end wonder if it was worth all the effort.
What’s your take on this? I’m interested to read other CRM developers opinion on this.