MS Dynamics CRM: Business Rules vs JavaScript

Business Rules were introduced as an out-of-the-box MS Dynamics CRM 2013 feature and provide CRM administrators with the ability to implement custom form logic via a simple to use designer UI. The designer UI enables non-technical individuals to implement interface driven business logic without the need for JavaScript. The end result is delivered faster and with less expense than custom script development.

Business Rules monitor the behaviour of fields on a form and define one or more actions to be performed when the conditions are met. The following are conditions that can be evaluated:

• Check a fields value against a static value
• Check a fields value against the value of another field on the same form
• String multiple conditions together separated by AND in one clause

The following defines the actions that can be performed when certain conditions are met on the form:

• Show error message
• Set field value
• Set field required or not
• Set field visibility
• Lock or unlock a field

Business rules are created for an entity:

 

Improvements have been made to Business Rules in MS Dynamics CRM 2015 and include:

• Rules to set default values for a field
• Support for if/else in their condition statements
• Support for and/or conditional rules
• Server side logic execution

Even with the improvements Business Rules cannot always satisfy complex business logic and administrators need to be able to identify when custom JavaScript development may be required. The following are some of the limitations of 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.
  • You can’t add more than ten if-else conditions in a business rule.
  • For Microsoft Dynamics 365 for tablets, the definition of the business rules are downloaded and cached when Dynamics 365 for tablets opens. Changes made to business rules are not applied until Dynamics 365 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.
  At the end of the day even with its limitation Business Rules are a powerful feature which enables the quick and cost effective implementation of custom form logic. And with future releases of MS Dynamics CRM we can only expect further improvements.

What is plugin dept in MS CRM Or stopping infinite loop in Plugin

Depth is often used to stop infinite loops where a plugin updates a value which triggers the plugin to run again.

A common cause of this is bad programming practice where a plugin retrieves the target entity and at the end of the plugin updates the entity.

e.g. 

1. A post plugin triggered on update of account name.

2. Plugin retrieves target entity

3. Plugin updates name field on target entity field to name + unique number

4. Plugin does CrmService.Update (target entity);

Plugin has updated field value which triggers plugin again The way around this is to put code in a pre plugin. 

It’s possible to check the depth of the plugin-

IPluginExecutionContext context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));

            if(context.Depth > 1)

                return;

Every time a running plug-in or Workflow issues a message request to the Web services that triggers another plug-in or Workflow to execute, the Depth property of the execution context is increased. If the depth property increments to its maximum value within the configured time limit, the platform considers this behavior an infinite loop and further plug-in or Workflow execution is aborted.

The maximum depth (8) and time limit (one hour) are configurable by the Microsoft Dynamics 365 administrator using the PowerShell command Set-CrmSetting.

The setting is WorkflowSettings.MaxDepth. For more information, see, “Administer the deployment using Windows PowerShell” in the Deploying and administering Microsoft Dynamics CRM.

Client-side events in MS CRM

Microsoft Dynamics CRM exposes events for forms, fields, and other controls. These are the event handlers where we can call our custom JavaScript methods.

We can configure our client-side code to execute on specific events or dynamically associate our method to a corresponding event. At beginning we will understand events related to forms.

Form Events

There are two events available for MS CRM form –

1.      OnLoad Event : The OnLoad event handler executes code when the entity form is loaded. We can utilize this event for controlling the behavior of entity forms and this event is useful for different scenarios. For example, we may want to hide/disable some fields based on other fields or based on the user security role. Business rules also utilize the OnLoad event to execute logic.

2.      OnSave Event : The OnSave event is executed when the entity form is saved; for example it is executed when the user clicks on the Save button in the lower-right corner of the screen. It is also executed automatically after 30 seconds if auto-save is enabled.

It can also be executed using the following methods:

Xrm.Page.data.entity.save

Xrm.Page.data.save

Xrm.Page.data.refresh

We can also stop the save event, if required. Let's take an example. When all the data has been entered on the entity form and the user wants to save it to the CRM database, but before sending it to the server, let's say we want to validate the data by the user; if the validation fails, you can cancel the save event. We can use following code to cancel the save event:

Xrm.Page.context.getEventArgs().preventDefault();

Field Events

All entity fields have one event exposed: the OnChange event. The OnChange event fires when focus from the field is lost. So, as soon as we tab out from a CRM field by entering or selecting some value, our custom JavaScript code associated with the OnChange event will fire.

This statement is not true for set value fields if they are formatted as a radio button or checkbox. The OnChange event for these fields fires immediately instead of executing after the focus is lost.

Control Events

Apart from form and field events, there are specific control events that we can use for implementing client-side logic. Following are the other common events.

TabStateChange :

The TabStateChange event is associated with the display state of tab control, so it fires when the tab control display state changes. We can use this event to control fields and other controls such as loading the IFRAME control.

OnReadyStateComplete

This event is associated with the IFRAME control and occurs when the content of the IFRAME is loaded fully.

PreSearch

This event is associated with lookup controls. We can utilize this to filter lookup controls based on our specific requirements. We can't configure this event through the UI; instead, we use addPreSearch and removePreSearch to associate our JavaScript function with the PreSearch event.