Business rules allow for defining logic that takes place in a form. Business rules provide an alternative to form scripts because they can be defined within a user interface without writing code
The business rule is fired when the form is loaded or updated only at the client CRM form.
Scope | Where it runs run |
Entity | All forms and server |
All forms | All forms |
Specific form | Just that form |
Here Client means the browser, if your business rules are not published using Entity, it will only run client side (browser), it does not means to specific user.
So for example I am changing something in entity form field associated with the business rule, it will fire . But if I am updating entity data using service call/SDK which do changes in server, business rule won't fire.
But in case of server side business rule, it will fire in above case.
In the top right of the form, use the Scope field to set the scope for the rule. “Entity” scope level is new in CRM 2015. Setting the scope of the business rule at an entity level, forces the business rule executed on both server and all clients side.
For example, on update of an entity record we will set “Description” field mandatory based on some conditions. So in this case we can create Business rule as below:
- Server Side Validation
To test this business rule validation on server side, we create a real time workflow to update this record which should trigger the validation logic:
Trigger the workflow from a record and get below error message immediately:
The record cannot be saved due to “Business Process Error”:
Download log file and we can find the trace details:
<TraceText>
[Microsoft.Crm.ObjectModel: Microsoft.Crm.ObjectModel.SyncWorkflowExecutionPlugin]
[1769c1b5-1784-e411-80c5-00155d016814: ] Starting sync workflow ‘Test Scope of Business Rule’, Id: 0e69c1b5-1784-e411-80c5-00155d016814
Entering UpdateStep1_step: Sync workflow ‘Test Scope of Business Rule’ terminated with error ‘Attribute ‘new_description’ cannot be NULL’
</TraceText>
- Client Side Validation To test this business rule in client side, we just simply update the record on the form and the error message show up as expected:
Conclusion:
To implement the same validation logic in previous CRM version, we have to develop plug-in in server side. Now CRM 2015 offers us a much simple way to apply the same logic on both server and all clients without writing coding. You can also set the rule select a specific form.
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.
Limitations of Business Rule:
- One of the limitations of business rules is that they are not executed during bulk edits and imports.
- We can’t debug and trace business rules like we do the JavaScript.
- The actions that can be performed using business rules are limited compared to the requirements a developer has to meet, like setting a field value by appending two other field values and hence forces them to depend on JavaScript.
- Also business rules are launched in the order they are activated. So one has to know all the business rules and the order in which they are to be executed in an entity.
- The number of If…Else statements in a business rule is limited to 10.
- The execution of a business rule is always enforced. There is no control over their execution. When a JavaScript and business rule acts on the same field of a form, the precedence is for System JavaScript followed by Custom JavaScript and then business rules.
- A JavaScript cannot be called from a business rule.
- A business rule can be acted only on the fields of local entities and not on the fields like look up of related entities or parent entities. Also business rules can’t interact with tabs and sections.
No comments:
Post a Comment