Here I will continue my series of posts aimed at helping anyone preparing for the MB2-712 certification. (Customization and Configuration in Microsoft Dynamics CRM 2016) This time my focus will be business rules.

Business rules are a great feature of Microsoft Dynamics as they allow us to configure rules to complete many actions on entities that previously would have required a developer to write JavaScript code. For example, with a business rule we can decide when fields are visible. Unlike workflows business rules are triggered as users interact with the form giving instant feedback.

With business rules we can create complex rules that conditionally effect the user experience by

• showing error messages,
• setting fields to specific values (or default values),
• making fields mandatory,
• hiding and showing fields
• enabling/ disabling fields

All of these changes would have needed the assistance of a developer in earlier versions of CRM but now they can be achieved simply with configuration. This doesn’t mean JavaScript is redundant as it may still be required if highly complex logic is required or when limitations of business rules come into play. For example, within a business rule we can hide and show fields on the form. But we can’t hide / show sections or tabs. If that was needed we’d still resort to JavaScript.

Another nice thing about business rules is we can define their scope, so that they can be applied to a specific form, all forms or even operate at an entity level. Business rules represent client-side logic that is applied on the form as the form is opened. Also, additionally, when defined as entity level the business rule logic can be applied at a server level. Meaning server side business rules run client-side and server-side. Entity level rule are triggered as users interact with the form AND they run on the server when a record is created or saved.

If we have a business rule that runs on a form that references a fields that isn’t a specific form it simply doesn’t run.

You may have already noticed that we have business rule options on the entity, form and even on fields. When viewing business rules, at an entity level we can see all the business rules. When we view the business rules from a form we’ll see all the rules that apply to that form. And if we view them from a field within a form we’ll see only the business rules which could use or impact that specific field. Meaning the rules are displayed from the perspective that they are being viewed.

Business Rules Scope

There are three options possible for the scope of a business rule;

1. Single Form Scope – Use this when a business rule specifically applies to a single form. It involves selecting a specific form name.
2. All Forms – Use this to apply the business rule to all forms. (Including main and quick create forms.)
3. Entity – Use this to run the business rule at a form and server level. (Server level being triggered by a create or update of data.) Useful if the rule is to be applied not only on forms but when data is imported.

Business Rules Example

The best way to explain business might be to show a quick example. Below you can see an example of a business rule.

Some things to notice, I have an if condition that says if policy type = “Car Insurance”. Then beyond this I have added an else if for policy type of “Life Insurance” and finally a default action as an Else.

Conditions, else if and else are all optional. But generally you will have at least one condition in a business rule. When creating the structure of your rule consider both sides of a condition. When a field is set to a value, say policy type to “Car Insurance” you will want something to happen. But also if the field changes you need to have that event covered. In my example car registration becomes mandatory if the policy type is “Car Insurance”. If the user incorrectly entered this value then you need to make sure an else condition would make it optional again.

After the conditions next notice the actions. My example is simple so I am just hiding fields and making them mandatory or not. Whilst a simple example it is important to understand that this is a very common use of business rules. Other actions types are available, as already mentioned.

When considering conditions in business rules it is important to be aware that a condition can have several parts and they can have and / or logic applied. (The default being and.)

Also a condition can be to check a field equals (or doesn’t) a particular value. You can also compare one field with another. Like in the example below when I say the modified user equals the owner of the record.

The operator on a condition can be one of many possibilities. Including obvious stuff like equals and does not equal. But also opens like contains or begins with are available. And with date and numeric values you have operators like is greater than, is less than etc.

Having created and saved your business rule, you will need to ensure it is activated. Once activated you need to deactivate the business rule to change it.

Each action has slightly different parameters. With set field, for example, you pick the field and then opt to set it to a value or another field. The best approach to learn how the different actions work will definitely be to try some out to see what happens.

I hope this post has given you a feel for how business rules work and some of the concepts you’ll need to cover for the MB2-712 exam. As always, this is an important area to get some hands-on experience of. J