With the first release of Dynamics CRM 2013 we now have the ability to implement client-side business logic without having to write javascript functions. This feature is named Business Rules. The purpose of this blog is to help you understand the pros and cons of business rules. The advent of Dynamics CRM has extended the capabilities within the business rules editor thus making them a bit more useful to handle even more business rules. However, business rules do have limitations and will not be able to eliminate the need for custom javascript. The content and examples provided below are from a Dynamics CRM 2015 org (PRIOR to the Spring 2015 release).

Benefits of Business Rules

Business Rules in Dynamics CRM 2015 allow non-developers the ability to generate javascript-like client-side logic using a designer that is somewhat like the Workflow Designer. It follows a similar design paradigm as the Workflow’s “Check Condition”. You can check field values against a static value or against another field’s value. This is actually smarter than Workflow’s check condition which does NOT allow you to compare to another field’s value. You can string multiple conditions together separated by AND in one clause. However, if you needed to set a series of OR conditions, you would have to treat each one as a separate IF…THEN clause.

For the THEN part of the IF..THEN formula you can perform any of these Actions with a Business Rule:

• Show an error message
• Set a field value
• Set a field’s requirement level to Required OR Not Required
• Set a field’s visibility to Show or Hide
• Set the Default value of a field
• Set a field’s Enablement level to be Editable or Locked

Limitations of Business Rules

1. Business Rules only let you work with local entity fields in the definition of the business logic. In other words, if your business logic will require any data from a parent entity or any related entity (through a lookup field) then you will need to use a javascript function, most likely using Odata, to read the related entity and perform the business logic.
2. Another factor to keep in mind when deciding whether to implement business logic via javascript or a business rule is this: do you need to control exactly when the function will be performed? You really don’t have control over when a business rule is fired. It is always being enforced. So, if you need to wait until say the Form Save event to enforce a piece of business logic, you’ll probably want to use a javascript function for this. Likewise, if you want to skip the enforcement of certain rules on a form load, and wait until other fields have been entered or changed by the user (i.e. the onchange event) it might be better to code this logic in javascript rather than a business rule.
3. Some business logic could require multiple business rules (prior to Spring 2015 release) or multiple clauses within one business rule (the Else clause was added to the designer). For example, in a time sheet / time entry app, we want to validate the total hours entered into decimal field called total hours. The business rule is that users can only enter 4 hrs or 8 hrs for administrative time entries (e.g. Bereavement, Jury Duty, Sick, Vacation). We will need separate rules or clauses to check for the following conditions: “less than 4 hrs was entered”, “more than 8 hrs was entered”, or “more than 4 but less than 8 hrs was entered”. this can be written more efficiently with javascript where you can more easily wrote OR conditions into your “IF statement”. The latter rule can be seen in the image below (on the left).
4. When your IF condition is “equal to” a specific lookup field value be aware of the following: the condition will be coded just like fetch xml…the GUID of the lookup record will be “hard-coded” into the rule. When you export that rule through a solution to another org, and import the solution, the rule will not work if the orgs have different GUIDs for the lookup records. In the example above, Vacation is a time category that resides in a custom entity named Time Category. If your DEV system is a different org than your production system, and each one used a csv import of time categories to load the Time Category entity then the GUIDs would be different. Hence you may be better of coding that business rule as a “begins with” comparison rather than an “equals” comparison.
5. Clearing the value of a field is not easily done in a Business Rule Action. You must create “dummy fields” of the same data type (text, option set, currency, date) and then set the field you want to clear equal to the value of the dummy field of the same type (since the dummy field is never displayed on a form its value should always be NULL). This can be seen in the image below (on the right).

Additional Things to Note about Business Rules and Javascripts

• Business rules only execute on the client-side form; they are not evaluated during bulk edits, bulk imports, plugin record updates, workflow record updates, etc.
• Business rules are run in order of activation, so if you need to tweek the order of execution, you’ll need to play with Deactivate and Activate to get the order just so
• When do business rules “run with respect to javascripts? The execution order is: System Javascripts (source code by Microsoft), Custom Javascripts, then Business Rules
• Business rules run on all CRM clients including all browser web clients, the Outlook client (offline and online), the CRM for Tablet clients
• When a business rule is used to set or change a field value, the Javascript OnChange event handler is NOT triggered
• You cannot call a Javascript method from a business rule

As Microsoft continues to enhance Dynamics CRM and future CRM releases are deployed we hope they will make more and more improvements in the Business Rules designer so that less and less custom javascript will need to be written to handle the enforcement of business logic on CRM forms. And as always, we hope this blog has given you some food for thought and helpful hints in implementing client-side business logic with Business Rules.

For more information about C5 Insight or this blog entry, please Contact Us.