MS CRM: Business Rules vs JavaScript
Business Rules were introduced as an out-of-the-box MS Dynamics CRM 2013 feature and provide CRM administrators with the ability to implement custom form logic via a simple to use designer UI. The designer UI enables non-technical individuals to implement interface driven business logic without the need for JavaScript. The end result is delivered faster and with less expense than custom script development.
Business Rules monitor the behaviour of fields on a form and define one or more actions to be performed when the conditions are met. The following are conditions that can be evaluated:
- Check a fields value against a static value
- Check a fields value against the value of another field on the same form
- String multiple conditions together separated by AND in one clause
The following defines the actions that can be performed when certain conditions are met on the form:
- Show error message
- Set field value
- Set field required or not
- Set field visibility
- Lock or unlock a field
Business rules are created for an entity:
The condition and action are defined:
When the business rule is triggered the following error message is displayed:
Improvements have been made to Business Rules in MS Dynamics CRM 2015 and include:
- Rules to set default values for a field
- Support for if/else in their condition statements
- Support for and/or conditional rules
- Server side logic execution
Even with the improvements Business Rules cannot always satisfy complex business logic and administrators need to be able to identify when custom JavaScript development may be required. The following are some of the limitations of Business Rules:
- Only fields associated with the local entity can be used in business rules. It will not be able to reference any data in related entities, for example in lookup fields.
- A business rule is always enforced. There is no control over when it executes, for example only when the form loads or saves.
- When a business rules changes the value of a property the onChange event for that property will not execute.
At the end of the day even with its limitation Business Rules are a powerful feature which enables the quick and cost effective implementation of custom form logic. And with future releases of MS Dynamics CRM we can only expect further improvements.
Business Rules were introduced as an out-of-the-box MS Dynamics CRM 2013 feature and provide CRM administrators with the ability to implement custom form logic via a simple to use designer UI. The designer UI enables non-technical individuals to implement interface driven business logic without the need for JavaScript. The end result is delivered faster and with less expense than custom script development.
Business Rules monitor the behaviour of fields on a form and define one or more actions to be performed when the conditions are met. The following are conditions that can be evaluated:
- Check a fields value against a static value
- Check a fields value against the value of another field on the same form
- String multiple conditions together separated by AND in one clause
The following defines the actions that can be performed when certain conditions are met on the form:
- Show error message
- Set field value
- Set field required or not
- Set field visibility
- Lock or unlock a field
Business rules are created for an entity:
The condition and action are defined:
When the business rule is triggered the following error message is displayed:
Improvements have been made to Business Rules in MS Dynamics CRM 2015 and include:
- Rules to set default values for a field
- Support for if/else in their condition statements
- Support for and/or conditional rules
- Server side logic execution
Even with the improvements Business Rules cannot always satisfy complex business logic and administrators need to be able to identify when custom JavaScript development may be required. The following are some of the limitations of Business Rules:
- Only fields associated with the local entity can be used in business rules. It will not be able to reference any data in related entities, for example in lookup fields.
- A business rule is always enforced. There is no control over when it executes, for example only when the form loads or saves.
- When a business rules changes the value of a property the onChange event for that property will not execute.
At the end of the day even with its limitation Business Rules are a powerful feature which enables the quick and cost effective implementation of custom form logic. And with future releases of MS Dynamics CRM we can only expect further improvements.
========================================================
CRM 2013 Business Rules vs. JavaScript - Who Wins?
A Business Rule in Dynamics CRM 2013 is a piece of functionality that allows system administrators a quick and easy way to incorporate some basic business logic and form manipulation into their organization without having to know JavaScript. Through a GUI in the customizations area, administrators can create simple If/Then type logic to set form field values, make fields required, hide & show fields, enable & disable fields or attach error messages to fields. One of the best parts is that any logic you define here can be applied to standard forms and the new Quick Create forms in the web client as well as forms in the new tablet client.
So what is happening here? The logic defined in the Business Rule is translated into JavaScript and applied to the form so that rules are checked both when the form loads and during the field's OnChange event.
But what happens when both a Business Rule and some JavaScript is applied to the same event on a field? As it turns out, the Business Rule comes out on top. I've put together a few illustrations.
I've created 2 Business Rules. The first shows an error message when the Account Number field equals 123456. The second sets the Account Number field value when the Account Name equals "New Account".
I've also created some JavaScript and attached it to the OnChange event of the appropriate fields to mimic the behavior of the Business Rules.
To test the first I'll set the Account Number to 123456...
The Business Rule won.
Next I'll set the Account Name to "New Account"...
The Business Rule won again.
So it would see that the 2 don't coexist well together. So for those of you out there that write JavaScript and end up responding to a report that functionality is no longer working, double check to see if any Business Rules were put in place that might be conflicting with your code.
But on the bright side, the 2 can work together. If we change the second rule so that instead of setting the Account Number's field value rather to display an error message, we can see that we get both results.
So what is happening here? The logic defined in the Business Rule is translated into JavaScript and applied to the form so that rules are checked both when the form loads and during the field's OnChange event.
But what happens when both a Business Rule and some JavaScript is applied to the same event on a field? As it turns out, the Business Rule comes out on top. I've put together a few illustrations.
I've created 2 Business Rules. The first shows an error message when the Account Number field equals 123456. The second sets the Account Number field value when the Account Name equals "New Account".
I've also created some JavaScript and attached it to the OnChange event of the appropriate fields to mimic the behavior of the Business Rules.
To test the first I'll set the Account Number to 123456...
The Business Rule won.
Next I'll set the Account Name to "New Account"...
The Business Rule won again.
So it would see that the 2 don't coexist well together. So for those of you out there that write JavaScript and end up responding to a report that functionality is no longer working, double check to see if any Business Rules were put in place that might be conflicting with your code.
But on the bright side, the 2 can work together. If we change the second rule so that instead of setting the Account Number's field value rather to display an error message, we can see that we get both results.
