Business Rules vs Client Script

Although Microsoft recommends implementing custom logic using configuration (such as Business Rules), it quickly becomes apparent that this approach has its limitations.

Business Rules can:

• Set field values and default values (triggered only on "create"). The value can be static or based on another field's value, but no additional data transformations are supported (e.g. string concatenation).
• Lock or hide controls.
• Set "business required" to either "Business required" or "Not business required," with no option for "Business recommended".
• Display error messages next to specific fields.
• Provide recommendations: display business rationale and, if the user accepts the recommendation, set the field's value to a static value, another field's value, or leave it empty.

Business Rules are enforced either at the entity or form level, so you don't have to worry about your script failing.

Make sure that users have a security role that includes, at a minimum, user scope read privileges on the Process table. Otherwise Business Rules may not be executed.

Business Rules have certain limitations that need to be considered:

• They cannot read if he field is disabled or hidden.
• They can only be applied to fields, not to grids, sections, or tabs. To hide a whole section, each control within the section must be hidden separately.
• They do not work with Multi-select choices 😢, unique identifier and rollup columns.
• They cannot retrieve related records. This must be done using client script (JavaScript) and Web API.
• They do not bubble events. If a control is changed by a Business Rule, it will not trigger its own Business Rule until the form is saved (or autosaved). It will also not trigger JavaScript events.
• They cannot check user's roles, or global settings like user's preferences (e.g., language),** organization settings, or client** information.
• There is no exception handling or debugging. You can see which Business Rules are loaded and in which order using Monitor.
• Only up to 10 if-else conditions are supported in a Business Rule. According to my experience, it maximum 9.
• Actions/conditions cannot be copied, which requires a lot of manual effort if your form is complex. However, you can copy Business Rules.
• Business Rules cannot call JavaScript, so there is no way to perform string/date operations like concatenating strings or getting timestamps.
• They won't fire on an editable grid when the editable grid is configured on a dashboard page.

Another issue is (probably an edge) scenario that I encountered creating a demo involved creating the following two Business Rules:

which results in a "cyclical reference" error once the second business rule is activated.

What runs first? Business rule or JavaScript?

Let's assume you have a Business Rule, and a client-script event handler defined for the same field.

JavaScript will execute first when it is attached to form events such as onLoad, onSave, or onChange. This is because JavaScript runs on the client side and can react immediately to user interactions on the form.

Business rules, on the other hand, are processed on the server side and are executed asynchronously.

Fields changed by a business rule will only trigger their own Business Rules once the form is saved (or auto saved). Field changes performed by Business Rules will not trigger JavaScript onChange event handler.

The demo below is configured as follows:

• F.BR is set by a Business Rule based on the value the a START field,
• F.JS is set by an onChange event handler associated with the START field,
• F.BR.BR is set by a Business Rule based on the F.BR field's value,
• F.BR.JS is set by an onChange event handler associated with the F.BR field,
• F.JS.BR is set by a Business Rule based on the F.JS field's vlaue
• F.JS.JS is set by an onChange event handler associated with the F.JS field.

As you see:

• fields changed by an onChange event handler will trigger Business Rules and client-side event handlers. Remember to call fireOnChange(), though.
• fields changed using Business Rules will not trigger client-side event handlers, and their own Business Rules will be executed once the form is saved.

Business rules execution sequence

The execution order of business rules can be managed based on their activation sequence.

To change the execution order:

• deactivate all business rules.
• activate them one by one in the desired order. The first activated rule will run first, and the last activated rule will run last. Yupp... 😶

How do you find the sequence then?

You can use Live Monitor to detect the execution order. Play your app, and filter the entries using Operation equals FormEvents.businessrule. Open the FormEvents.businessrule side panel and expand data, FormEvents.

For business rules activated in alphabetical order:

And once the rules are activate in descending order:

However, remember that they execute asynchronously. Even if you change the execution order, you cannot count on the first business rule completing before the next one is triggered.