Create and edit business rules Dynamics CRM 2015

Why business rules?

Business rules provide an easy declarative way to consistently evaluate the business logic on both client and server, without the need to write code. The client-side logic evaluation is more immediate because it is performed when you open and update the record form, while the server-side provides consistent logic evaluation on the server.

• The business rule is executed only on the client, if the rule’s scope is set at a form level (all forms or a specific form). The rules are executed when a record form is loaded and updated.
• The business rule is executed both on the server and client, if the rule’s scope is set at an entity level. The rules on the server-side are executed when a record is created or saved.

What can business rules do?

Business rules allow for a subset of the capabilities provided by form scripts. You can define conditions and apply the following actions:

• Set field values
• Clear field values
• Set field requirement levels
• Show or hide fields
• Enable or disable fields
• Validate data and show error messages

Business rules can be set to apply to all Main or Quick Create entity forms or specific Main forms that you choose. You can also set the rule to apply to an entity.

You can transport business rules from one organization to another by including them in a solution and you can install solutions that contain business rules.

Among the slew of improvements in the Dynamics CRM 2015 Update is a refresh to Business Rules which fixes this these restrictions and adds wider functions.

This includes:

• Support for enriched business logic including if / else
• Combining expressions using and / or conditional rules
• Using Rules to set default field values
• Synchronous server side Business Rule logic execution
• Visual editing

Set the scope

In the top right of the form, use the Scope field to set the scope for the rule.

Scope	Where it runs run
Entity	All forms and server
All forms	All forms
Specific form	Just that form

You cannot select multiple specific forms. If you choose All Forms, the rule will be applied to all the Main forms and the Quick Create form, as long as the form includes all the fields referenced by the rule. If you create a new business rule by using the form editor, the default scope is just that form.

Server side business rules and support for IF-Else and AND/OR logic

Previously, you had an ability to evaluate the business rules on an individual client. To evaluate the business rule logic on the server and apply it to all clients, you had to provide the plug-ins, which are expensive to develop and maintain. Setting the scope of the business rule at an entity level, gives you an ability to evaluate the business rule once on the server and apply it to all clients without writing code. You can move the logic for commonly used scenarios out of plug-ins into the entity-level business rules. In addition, we provided the support for default values in a business rule. For instance, if Contoso only does business in the United States, a simple business rule can be implemented that on creation of an incoming lead, the country/region is automatically set to U.S.A.

Limitations for business rules

Business rules are intended to address common actions. Compared to what a developer can do by using form scripts, business rules have limitations. However, business rules are not intended to replace form scripts.

Here are a few limitations to using business rules:

• Business rules run only when the form loads and when field values change. They do not run when a record is saved, unless the scope for the rule is set at an entity level.
• Business rules work only with fields. If you need to interact with other visible elements, such as tabs and sections, within the form you need use form scripts.
• When you set a field value by using a business rule, any OnChange event handlers for that field will not run. This is to reduce the potential for a circular reference, which could lead to an infinite loop.
• If a business rule references a field that is not present on a form, the rule will simply not run. There will be no error message.
• Whole Number fields that use the formats for TimeZone, Duration, or Language will not appear in the rule editor for the conditions or actions, so they cannot be used with business rules.
• For Microsoft Dynamics CRM for tablets, the definition of the business rules are downloaded and cached when CRM for tablets opens. Changes made to business rules are not applied until CRM for tablets is closed and re-opened.
• When you set the value of a lookup field, the text of the primary field value that is set in the form will always match the text that is visible in the rule definition. If the text representing the primary field value of the record you are setting in the lookup changes, the value set by your rule will continue to use the text portion of the primary field value defined by the rule. To fix this, update the rule definition to use the current primary name field value.
  
  
  
  It is useful to understand that the value set for a lookup has three parts:
• Name: The text of the primary field value you see in the form.
• Id: The unique identifier for the record. This is the data that is saved. This is not visible in the form.
• LogicalName: The name of the entity, such as contact, account, or opportunity.

The rule will set all three parts of this value. The Id value for a specific record never changes, but the Name value might change.

For example, if you define a rule to set a lookup to a contact that has the Full Name of ‘Old Name’, this text is the Name you will see in the lookup when it is set by your business rule even if someone later changes the Full Name of the contact to ‘New Name’. The lookup Id value will be correctly set to the expected record, but the Name(which is not saved) will reflect the rule definition value rather than the current Full Name value of the record it references.