One of the less utilised/understood feature of Business Rule is Process Triggers. In this post, I will explain what a process trigger is and how you can use this in the context of business rule.
The Basics
Business Rule is basically a workflow that has a different UI compared to the standard workflow editor. You can quickly find all the business rules in your CRM instance by running this query.
Internals – How does Business Rules work
You can basically skip this part, if you are not interested in understanding the internals on how a business rules work. When you create a business rules you basically have all these components that make the business rules run seamlessly:
- The client side code that runs on the form
- The server side workflow defined in xaml
- Process trigger -> This dictates when the business rule logic should execute
When you design a business rule, it is automatically translated into a workflow xaml that executes on the server side and JavaScript code that executes on the client side.
Now, let us take a simple example of a business rule that sets the “Salutation”, when “Gender” is changed. Here is the business rule
When you save this business rule, this is automatically translated into JavaScript, code that can run on the client side. Below is the JavaScript code that is generated by CRM, for this business rule:
function pbl_109af564df34e51180eac4346bc576e8() {
try {
var v0 = Xrm.Page.data.entity.attributes.get('gendercode');
var v1 = Xrm.Page.data.entity.attributes.get('salutation');
if (((v0) == undefined || (v0) == null || (v0) === "") || ((v1) == undefined || (v1) == null || (v1) === "")) {
return;
}
var v2 = (v0) ? v0.getValue() : null ;
if ((v2) === (1)) {
v1.setValue('Mr');
} else if ((v2) === (2)) {
v1.setValue('Ms');
}
} catch (e) {
Mscrm.BusinessRules.ErrorHandlerFactory.getHandler(e, arguments.callee).handleError();
}
}
Below is the JavaScript code this calls the “pbl_109af564df34e51180eac4346bc576e8” function that contains the logic for the business rule.
Mscrm.BusinessRulesScript.Initialize = function() {
Mscrm.BusinessRulesScript.AttributesOnChangeHandlers = {};
Mscrm.BusinessRulesScript.ControlsOnClickHandlers = {};
(function() {
var onchangehandler = function() {
pbl_109af564df34e51180eac4346bc576e8();
}
;
Mscrm.BusinessRulesScript.AttributesOnChangeHandlers['gendercode'] = onchangehandler;
var attributeObject = Xrm.Page.data.entity.attributes.get('gendercode');
if (attributeObject != null && attributeObject != undefined) {
attributeObject.addOnChange(onchangehandler);
}
})();
pbl_109af564df34e51180eac4346bc576e8();
};
From the above, triggering code we can see that the business rule is going to run when the form is opened, as the function “pbl_109af564df34e51180eac4346bc576e8” is called when the business rule is initiated. The function also executes when “Gender” is changed.
If you want to know what the generated JavaScript code for the business rule is, just get the “ClientData” field in the “Workflow” entity. You cannot get this field from Advanced Find. You can either use FetchXML Builder (a XrmToolBox tool) or LINQPad. Below is the fetchxml query, I used.
If you also get the “xaml” field on the workflow entity, you can see the markup server side workflow logic that will execute.
Process Trigger
Process Trigger dictates the events that will trigger the execution of business rule. There are three events:
- Load
- Change
- Save
“Load” and “Change” are the standard triggers when the business rule is created through the UI. “Save” is a special handler. It can only be set using the SDK and not through the UI. It behaves little differently compared to “Load”. The JavaScript code that is generated for “Save” is little different compared to the code that is generated for “Load”. Here is the LINQ query I used for getting process triggers for this workflow.
Now let us update the “load” trigger to “save”, so that the generated JavaScript for the business rule will run only on “Form Save” event and not on “Form Load”. Here is the simple snippet I ran to do this, after I got the ids of the process trigger in the previous LINQ Query. These process triggers are for the “load” events associated to our business rule. You have to deactivate the business rule, before you update the process trigger for the business rule.
Now comes the important bit: Activate the business rule from the Advanced Find results (first screenshot). Don’t activate the business rule from the standard business rule window. If you activate the business rule from the standard UI, your process trigger will reset back to “load”
Now that the trigger is set to “Save”, lets compare the generated JavaScript code.
As we can see, in the case of “save” process trigger, the client side business rule code runs only on “Save”. I like this, because I don’t want the business rule to run on “load” and confuse the user with “Unsaved changes” message. I will demonstrate this with a scenario.
Scenario: User opens a contact record, which doesn’t have the “Salutation” field set. Gender contains a valid value. The process trigger is “load”
As you can see from the above screenshot, the business rule ran immediately on form load, and set the Salutation to “Mr”. Hence, you have a unsaved changes message, on the bottom right. I am not very happy with this result because, it is not obvious to the user what changed and what caused the change. I want more control, so I want this rule to run only after “Save”. Now look at the same form, when the trigger is “Save”
As you can see, the “Salutation” field is not set immediately. It will be set only
- When the form is saved OR
- When the “Gender” field is changed
One more thing: Every time when you deactivate and reactivate a business rule, new process triggers records are created, and so you have to get the correct ids when you update the “event” attribute.
I hope you can now understand the internals of business rule and how to use process trigger to control its behaviour.
References:
- TechNet: Create and edit business rules
- MSDN – Create or edit how business rules are initiated
