The official definition from Microsoft is:
Simple declarative interface to implement and maintain fast changing commonly used business rules that will be applied to main and quick view forms or to an entity.
So what does that really mean in terms of the application and data? First, let’s talk about what is a business rule. Wikipedia defines a business rule as:
A business rule is a rule that defines or constrains some aspect of business and always resolves to either true or false. Business rules are intended to assert business structure or to control or influence the behavior of the business.
This is all fine and dandy but in terms of application development we need to understand exactly what we’re doing here. For the most part our applications work with data that is collected either through user entry or through application calculations. Business rules can alter , constrain, require or validate that data depending on how the business has defined it’s behaviour.
So for instance, a business could have rules about bulk discounts. Buy 10 ACME widgets and get a 10% discount, buy 100 ACME widgets and get a 20% discount. When a developer looks at the rule, we have to look at it as data that is being changed or constrained depending on what is in the rule. In this discount example, we have a discount amount being applied to a order based on a quantity of items being purchased. Based on a value of one data point you can an action occur. It’s best to list out our data points like so:
- Discount Amount – Value Effected
- Quantity of Product – Restricting Value
- Form or Entity – Application Interface
Business rules to a developer are more like interactions between data points. My example is a pretty simple example but they can get a lot more complex.
Normally in a business rule, you’ll have a value that will be changed, restricted, required, validated or hidden based on a value in another field or possibly a generality from the business itself. The rule will affect how an application interface allows a user to interact with the data.
Other examples include when you have to set required values, validate the data entered, enable/disable, show/hide or clear values based on some restricting value or business requirement. I say that because in some instances you’ll find that a piece of data has to be supplied by a user regardless of other values. However, if you list out the data points and name that it becomes easier to translate the business rule into MS Dynamics CRM’s business rule engine.
Business rules in MS Dynamics CRM have certain limitations regarding what they can do and they do have a scope level within the application to consider. I’ll cover more about working with them in future posts.
More information about creating and editing business rules can be found on Microsoft’s TechNet or by downloading their Administration Guide.
Additional Information about Business Rules and Business Requirements: