When you develop model driven apps, business rules can be very useful.
Introduction to business rules
In this posts I will look at the business rules and how they work.
In my example I have already created an entity called Fruit in my Common Data Services. The entity has two fields, Name and Colour.
I only want the colour field to be available when the Name of the fruit is Apple.
So for an Orange, the Colour field will disappear. While for an Apple we want to show the Colour field. It is quite obvious which colour oranges are!

And for Apple the field will appear as shown below in my Model Driven Apps

If we had to do this in code this would probably look a bit like this. This code is also shown by the Business Rule editor. It is quite helpful to check when things go unexpectedly wrong!
IF
Name equals "Apple"
THEN
Show field Colour
ELSE
Hide field Colour
Within the Business rule editor however, the rule can be ‘coded’ like this:

Ok, this is all easy.
Now I’m going to add some more logic. As grapes can also come in different colours I’m adding a second condition that will check if my fruit is a grape.

As you will notice in the above screenshot, it is important to name each box properly. It would have been nice if the logic was somehow represented in each box as well. But while that isn’t there the descriptions become critical.
As you change the description make sure that you hit the apply button! It isn’t always visible, but it is there when you scroll down!

As you make your changes to a business rule it is important to deactivate the rule first and after all the updates you will need to activate the rule again.
So our new logic is something like this
IF
Name equals "Apple"
THEN
Show field Colour
ELSE IF
Colour equals "Grape"
THEN
Show field Colour
ELSE
Hide field Colour
Resulting in the following business rule:

These multiple conditions may then well work, but is can be wise to follow the location described below. Keeping the number of steps in the overall business rule down.
Then I tried like this where the condition checks if the Name field is set to Grape or Apple and then disable the colour field as required.

This worked! The condition in the above is set as shown below:

It is however possible to make Business Rules with multiple conditions work in Model Driven Apps. It could look like this:

Other things we can do with Business Rules
So far we have seen the option to Show or hide fields in the forms. Other actions you can handle with business rules are:
- Set field values
- Clear field values
- Set field requirement levels
- Enable or disable fields
- Validate data and show error messages
- Create business recommendations based on business intelligence
Limits of Business Rules
You might want to add multiple conditions however you can only add more conditions to the negative part of the branch of parent conditions. Multiple conditions in the true branch are in general not really needed. You could simply add more and/or logic in the existing conditions.

When do Business Rules fire?
This is actually a very important question and important to understand. When a form is loaded the business rules will be applied.
Additionally when data changes in your form the rules are run as well. Making it possible for a form to be dynamic as the user completes the data entry process.
[…] When you develop model driven apps, business rules can be very useful. Introduction to business rules In this posts I will look at the business rules and how they work. … read the business-rules-in-model-driven-apps post […]
can we execute the business rules from a program ? (ex: console app) does this have a dll that i can use ?
Hi Nen,
Business rules start on data changes in an entity or on a form. So form wihtin you app you can make a rule kick in by updating data within a form.